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Foreword 

This final draft 2nd edition of European Telecommunication Standard (ETS) has been produced by the 
Joint Technical Committee (JTC) of the European Broadcasting Union (EBU), Comite Europeen de 
Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute 
(ETSI), and is now submitted for the Voting phase of the ETSI standards approval procedure. 

NOTE: The EBU/ETSI JTC was established in 1990 to co-ordinate the drafting of ETSs in the 
specific field of broadcasting and related fields. Since 1995 the JTC became a tripartite 
body by including in the Memorandum of Understanding also CENELEC, which is 
responsible for the standardization of radio and television receivers. The EBU is a 
professional association of broadcasting organizations whose work includes 
co-ordination of its Members' activities in the technical, legal, programme-making and 
programme-exchange domains. The EBU has Active Members in about 60 countries 
in the European Broadcasting Area; its headquarters is in Geneva *. 



European Broadcasting Union 
Case Postale 67 

CH-1218 GRAND SACONNEX (Geneva) 
Switzerland 




Tel: +41 22 717 21 11 
Fax: +41 22 717 24 81 
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Date of withdrawal of any conflicting National Standard (dow): 


6 months after doa 
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1 Scope 

This 2nd edition of European Telecommunication Standard (ETS) specifies the Service Information (SI) 
data which forms a part of Digital Video Braodcasting (DVB) bitstreams, in order that the user can be 
provided with information to assist in selection of services and/or events within the bitstream, and so that 
the Integrated Receiver Decoder (IRD) can automatically configure itself for the selected service. SI data 
for automatic configuration is mostly specified within ISO/IEC 13818-1 [1] as Program Specific Information 
(PSI). This ETS specifies additional data which complements the PSI by providing data to aid automatic 
tuning of IRDs, and additional information intended for display to the user. The manner of presentation of 
the information is not specified in this ETS, and IRD manufacturers have freedom to choose appropriate 
presentation methods. 

It is expected that Electronic Programme Guides (EPGs) will be a feature of Digital TV transmissions. 
The definition of an EPG is outside the scope of the SI specification, but the data contained within the SI 
specified here may be used as the basis for an EPG. 

Rules of operation for the implementation of ETS 300 468 are specified in ETR 21 1 [7]. 

2 Normative references 

This ETS incorporates by dated and undated reference, provisions from other publications. These 
normative references are cited at the appropriate places in the text and the publications are listed 
hereafter. For dated references, subsequent amendments to or revisions of any of these publications 
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest 
edition of the publication referred to applies. 



[1] ISO/IEC 13818-1: "Information Technology - Generic Coding of Moving Pictures 

and Associated Audio Recommendation H.222.0 (systems)". 

[2] ISO 3166: "Codes for the representation of names of countries". 

[3] ISO 639.2: "Code for the representation of names of languages". 

[4] EBU SPB 492: "Teletext specification (625 line Television Systems)". 

[5] ISO 8859: "Information processing - 8-bit single-byte coded graphic character 

sets, Latin alphabets". 

[6] ETR 162; "Digital broadcasting systems for television, sound and data services; 

Allocation of Service Information (SI) codes for Digital Video Broadcasting 
(DVB) systems". 

[7] ETR 211: "Digital broadcasting systems for television; Guidelines on 

implementation and usage of service information". 

[8] ISO/IEC 10646-1: "Information Technology - Universal Multiple-Octet Coded 

Character Set (UCS) - Part 1 : Architecture and Basic Multilingual Plane". 

[9] ISO/IEC 6937: "Information Technology - Coded graphic character set for text 



communication - Latin alphabet". 
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3 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of this ETS, the following definitions apply: 
bouquet: A collection of sen/ices marketed as a single entity. 

broadcaster (SERVICE provider): An organization which assembles a sequence of events or 
programmes to be delivered to the viewer based upon a schedule. 

component (ELEMENTARY stream): One or more entities which together make up an event, 
e.g. video, audio, teletext. 

Conditional Access (CA) system: A system to control subscriber access to sen/ices, programmes and 
events e.g. Videoguard, Eurocrypt. 

delivery system: The physical medium by which one or more multiplexes are transmitted e.g. satellite 
transponder, wide-band coaxial cable, fibre optics. 

Entitlement iVianagement Messages (EMM): Are private Conditional Access information which specify 
the authorization levels or the sen/ices of specific decoders. They may be addressed to individual decoder 
or groups of decoders. 

\t event: A grouping of elementary broadcast data streams with a defined start and end time belonging to a 
£> common sen/ice, e.g. first half of a football match, News Flash, first part of an entertainment show. 

forbidden: The term "forbidden" when used in the clauses defining the coded bit stream, indicates that 
the value shall never be used. 

MPEG-2: Refers to the standard ISO/IEC 13818 [1]. Systems coding is definedi n part 1. Video coding is 
defined i n part 2. A udio coding is defined in part 3. ~~ " — ""^ ' 

multiple x: A stream of all the digital data carrying one or more services within a single physical channel. 



network: A collection of MPEG-2 Transport Stream multiplexes transmitted on a single delivery system, 
e.g. all digital channels on a specific cable system. 

originaLnetworkJd: A unique identifier of a network. 

programme: A concatenation of one or more events under the control of a broadcaster e.g. news show, 
entertainment show. 

reserved: The term "reserved" when used in the clause defining the coded bit stream, indicates that the 
value may be used in the future for ISO defined extensions. Unless otherwise specified within this ETS all 
"reserved" bits shall be set to "1 

reserved_future_use: The term "reserved_future_use", when used in the clause defining the coded bit 
stream, indicates that the value may be used in the future for ETSI defined extensions. Unless otherwise 
specified within this ETS all "reserved_future_use" bits shall be set to "1". 

section: A section is a syntactic structure used for mapping all service information defined in this ETS into 
ISO/IEC 1381 8 [1] Transport Stream packets. 

service: A sequence of programmes under the control of a broadcaster which can be broadcast as part of 
a schedule. 

^ servicejd: A unique identifier of a s ervice within a transport stream. 

Service Information (SI): ^igit al data describing the delivery system, content a nd sc heduling/timing of 
broadcast data streams etcTltincrudes MPEG-2 PSLtoq ether with indeipaTaerW ^efin^"extensions ~" 
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sub_table: A sub_table is collection of sections with the same value of tablejd and: 
for a NIT: the same table_id_extension (networkjd) and version_number; 
for a BAT: the same table_id_extension (bouquet_ld) and version_number; 

for a SDT: the same tableJd_extension (transport_stream Jd), the same originaLnetworkJd 
and version_number; 

foraEIT: the same tab!e_id_extension (servicejd), the same transport_streamJd. the same 
originaLnetworkJd and version_number. 

The table Jd„extension field is equivalent to the fourth and fifth byte of a section when the 
section_syntaxJndicator is set to a value of "1 ". 

table: A table is comprised of a number of sub_tables with the same value of tablejd. 

Transport Stream (TS): A Transport Stream is a data structure defined in ISO/IEC 13818-1 [1]. It is the 
basis of the ETSi Digital Video Broadcasting (DVB) standards. 

transport_streamJd: A unique identifier of a transport stream within an original network. 

The relationships of some of these definitions are illustrated in the service delivery model in figure 1 . 



Networks 




Components 



Figure 1: Digital broadcasting, service delivery model 
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3.2 Abbreviations 



For the purposes of this ETS, the following abbreviations apply: 



RAT 
DM 1 


oouCfUei Associaiion i auie 




f^Imna^i /^A^A^ P^^^aIimaI 

Binary Codea L)ecimal 


OS IDT 


bit stnng, left bit first 




Conditional Access 


AT" 


Conditional Access Table 




Cyclic Redundancy Check 


UVd 


Digital Video Broadcasting 


crcai 1 


European Broadcasting Union 


cIT 


Event Information Table 


[=Mlv] 


Entitlement Management Message 


tPG 


Electronic Programme Guide 


t 1 O 


European Telecommunication Standard 


ETSI 


European Telecommunications Standards Institute 


FEC 


Forward Error Correction 


ICO 


Intemational Electrotechnical Commission 


IRD 


Integrated Receiver Decoder 


loU 


Intemational Organisation for Standardisation 


IT*0 


Joint Technical Committee 




Least Significant Bit 


MJU 


Modrfied Julian Date 


^>IDco 


Moving Pictures Expert Group 


MIT 


Network Information Table 


NVOD 


Near Video On Demand 


DAT 

rA 1 


Program Association Table 


Din 


Packet IDentifier 


Oft 

PMT 


Program Map Table 


DO 1 


Program Specific Information 


PSTN 


Public Switched Telephone Network 


A ft Jl 

QAM 


Quadrature Amplitude Modulation 




Quaternary Phase Shift Keying 


rpcnoT 


remainder polynomial coefficients, highest order first 


r\o 


Reed Solomon 


RST 


Running Status Table 


SDT 


Service Description Table 


SI 


Service Information 


ST 


Stuffing Table 


TDT 


Time and Date Table 


TOT 


Time Offset Table 


TS 


Transport Stream 


uimsbf 


unsigned integer most significant bit first 


UTC 


Universal Time. Co-ordinated 



4 Service Information (SI) description p ^^u^U^^ Q ^<3 //^J B^C./tA'^^Z^ 

ISO/IEC 13818 [1] specifies SI which is referred to as PSI. The PS! data provides information to enable y^^^^'^^ 
automatic configuration of the receiver t o demultiplex and de code the various streams of proqrams within ( ''T^ fnJ- 
the multiplex. • I 



The PSI data is structured as four types of table. The tables are transmitted in sections. 

1 ) Program Association Table (PAT): 

for each service in the multiplex, the PAT indicates the location (the PID values of the 
Transport Stream packets) of the corresponding Program Map Table (PMT). It also gives the 
location of the Network Information Table (NIT). 
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2) Conditional Access Table (CAT): 

the CAT provides information on the Conditional Access (CA) systems used in the multiplex; 
the Information is private (not defined within this ETS) and dependent on the CA system, but 
includes the location of the EMM stream, when applicable. 

3) Program Map Table (PMT): 

the PMT identifies and indicates the locations of the streams that make up each service, and 
the location of the Program Clock Reference fields for a service. 

4) Network Information Table (NIT): 

the location of the NIT is defined in this ETS in compliance with ISO/IEC 13818-1 [1] 
specification, but the data format is outside the scope of ISO/IEC 13818-1 [1]. It is intended 
to provide information about the physical network. The syntax and semantics of the NIT are 
defined in this ETS. 

In addition to the PSI, data is needed to provide identification of services and events for the user. 
The coding of this data is defined in this ETS. In contrast with the PAT. CAT, and PMT of the PSI, which 
give information only for the multiplex in which they are contained (the actual multiplex), the additional 
information defined within this ETS can also provide information on services and events carried by 
different multiplexes, and even on other networks. This data is structured as six tables : 

1 ) Bouquet Association Table (BAT): 

the BAT provides information regarding bouquets. As well as giving the name of the bouquet, 
it provides a list of services for each bouquet. 

2) Service Description Table (SDT): 

the SDT contains data describing the services in the system e.g. names of services, 
the service provider, etc. 

3) Event information Table (EIT): 

the EIT contains data concerning events or programmes such as event name, start time, 
duration, etc.; 

the use of different descriptors allows the transmission of different kinds of event information 
e.g. for different service types. 

4) Running Status Table (RST): 

the RST gives the status of an event (running/not running). The RST updates this information 
and allows timely automatic switching to events, 

5) Time and Date Table (TDT): 

the TDT gives information relating to the present time and date. This information is given in a 
separate table due to the frequent updating of this information. 

6) Time Offset Table (TOT): 

the TOT gives information relating to the present time and date and local time offset. 
This infomnation is given in a separate table due to the frequent updating of the time 
information. 

7) Stuffing Table (ST): 

the ST is used to invalidate existing sections, for example at delivery system boundaries. 
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Where applicable the use of descriptors allows a flexible approach to the organization of the tables and 
allows for future compatible extensions. 



MPEG-2 defined 


Defined in this ETS 




PID = 0 




PID =0x0010 




PID = 0x0010 






PAT 




NIT 

Actual delivery 
system 




NIT 

Other delivery 
system 


Network 
information 


PID = 1 




PID= 1x0011 




PID = 1x0011 






CAT 




SDT 

Moiual 1 icinspon 
stream 




SDT 

Other Transport , 
Stream 


Service 
description 


PID = P 




PID = 0x0012 




PID = 0x0012 






PhAT 


1 : 

• 

• 

• 


EiT 

Actual Transport 
Stream 

Present/foHowing 




EIT 

Other Transport 
stream 

Present/foflowing 


Event 

. information 






Schedule 




Schedule 








rIL) = 0x0014 




PID = 0x0013 




PID = 0x0011 




TDT 


Time 
date 


RST 


Running 
status 




BAT 


Bouquet 
association 






PID = 0x0014 












TOT 


Time 
Offset 




















PID = 0x0010 to 0x0014 










ST 


stuffing 















Figure 2: General organization of the SI 
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5 The SI tables 

5.1 SI table mechanism 

The SI specified in this ETS and MPEG-2 PSI tables shall be segmented into one or more sections before 
being inserted into Transport Stream packets. The tables listed in clause 4 are conceptual in that they 
need never be regenerated in a specified form within an IRD. The tables, when transmitted shall not be 
scrambled, with the exception of the EIT, which may be scrambled if required (see subclause 5.1.5). A 
section is a syntactic structure that shall be used for mapping all MPEG-2 tables and SI tables specified in 
this ETS, into Transport Stream packets. These SI syntactic structures conform to the private section 
syntax defined in ISO/IEC 13818-1 [1]. 

5.1.1 Explanation 

Sections may be variable in length. The sections within each table are limited to 1 024 bytes in length, 
except for sections within the EIT which are limited to 4 096 bytes. Each section is uniquely identified by 
the combination of the following elements: 

a) tablejd: 

The tablejd identifies to which table the section belongs. 

Some tablejds have been defined by ISO and others by ETSI. Other values of the tablejd 
can be allocated by the user for private purposes. The list of values of tabiejd is contained in 
table 2. 

b) table Jd_extension: 

The table Jd_extension is used for identification of a subjable. 
The interpretation of each subjable is given in subclause 5.2. 

c) section_number: 

The section_number field allows the sections of a particular subjable to be reassembled in 
their original order by the decoder. It is recommended, that sections are transmitted in 
numerical order, unless it is desired to transmit some sections of the subjable more 
frequently than others, e.g. due to random access considerations. 

For the SI tables as specified in this ETS, section numbering applies to sub_tables. 

d) version_number: 

When the characteristics of the Transport Stream described in the SI given in this ETS 
change (e.g. new events start, different composition of elementary streams for a given 
service), then new SI data shall be sent containing the updated information. A new version of 
the SI data is signalled by sending a subjable with the same identifiers as the previous 
subjable containing the relevant data, but with the next value of version_number. 

For the SI tables specified in this ETS, the version_number applies to all sections of a 
subjable. 

e) Current_nextJndicator: 

Each section shall be numbered as valid "now" (current), or as valid in the immediate future 
(next). This allows the transmission of a future version of the SI in advance of the change, 
giving the decoder the opportunity to prepare for the change. There is however, no 
requirement to transmit the next version of a section in advance, but if it is transmitted, then it 
shall be the next correct version of that section. 
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5.1.2 Mapping of sections into Transport Stream packets 

Sections shall be mapped directly into Transport Stream packets. Sections may start at the beginning of 
the payload of a Transport Stream packet, but this is not a requirement, because the start of the first 
section in the payload of a Transport Stream packet is pointed to by the pointer_field. There is never more 
than one pointer_field in a Transport Stream packet, as the start of any other section can be identified by 
counting the length of the first and any subsequent sections, since no gaps between sections within a 
Transport Stream packet are allowed by the syntax. 

Within Transport Stream packets of any single PID value, one section is finished before the next one is 
allowed to be started, or else it is not possible to identify to which section header the data belongs. If a 
section finishes before the end of a Transport Stream packet, but it is not convenient to open another 
section, a stuffing mechanism may be used to fill up the space. 

Stuffing may be performed by filling each remaining byte of the Transport Stream packet with the value 
"OxFF". Consequently the value "OxFF" shall not be used for the tablejd. If the byte immediately following 
the last byte of a section takes the value of "OxFF", then the rest of the Transport Stream packet shall be 
stuffed with "OxFF*" bytes. These bytes may be discarded by a decoder. Stuffing may also be perfonmed 
using the adaptation_field mechanism. 

For a more detailed description of the mechanism and functionality, specifically refer to section 2.4.4 and 
annex C of ISO/IEC 13818-1 [1]. 

5.1 .3 Coding of PID and tablejd fields 

Table 1 lists the PID values which shall be used for the Transport Stream packets which carry 
SI sections. 



Table 1 : PID allocation for SI 



Table 


PID value 


PAT 


0x0000 


CAT 


0x0001 


reserved 


0x0002 to OxOOOF 


NIT, ST 


0x0010 


SDT. BAT. ST 


0x001 1 


EIT, ST 


0x0012 


RST, ST 


0x0013 


TOT. TOT. ST 


0x0014 


reserved for future use 


0x0015 to 0x001 F 



Table 2 lists the values which shall be used for tablejd for the service infonmation, defined in this ETS. 
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Table 2: Allocation of tablejd values 



Value 


Description 


0x00 


program_associatlon_section 


0x01 


conditional access section 


0x02 


progrann„map_section 


0x03 to 0x3F 


reserved 


0x40 


network_information_section - actual_network 


0x41 


networkjnformation section - other network 


0x42 


service descriotion section - actual transnort <;trp;5m 


0x43 to 0x45 


reserved for future use 


0x46 


service descriotion section - other tran«;nnrt ^itrp^im 


0x47 to 0x49 


reserved for future use 


0x4A 


bouQuet_association section 


0x4B to 0x4D 


reserved for future use 


0x4E 


event information section - pctii^l tranQnort Qtroam nrocont/fr»iin\A/inn 


0x4F 


event information section - other transnort citrpam nr#ac:ont/fniir»\A/inn 


0x50 to 0x5F 


event information section - act iial trancinnrt <;trAam q/^HoHmIo 


0x60 to 0x6F 


eventJnformation_section - other_transport stream, schedule 


0x70 


time_date_section 


0x71 


running_status_section 


0x72 


stuffing_section 


0x73 


time_offset_section 


0x74 to 0x7F 


reserved for future use 


0x80 to OxFE 


user defined 


OxFF 


reserved 



5.1-4 Repetition rates and random access 

In systems where random access is a consideration, it is recommended to re-transmit SI sections 
specified within this ETS several times, even when changes do not occur in the configuration. 

For SI specified within this ETS the minimum time interval between the arrival of the last byte of a section 
to the first byte of the next transmitted section with the same PID, tablejd and tableJd_extension and 
with the same or different section_number shall be 25 milliseconds. This limit applies for 
Transport Streams with a total data rate of up to 100 Mbit/s. 

5.1.5 Scrambling 

With the exception of the EIT carrying schedule information, all tables specified in this ETS shall not be 
scrambled. One method for scrambling the EIT schedule table is given in the Bibliography 2). If a 
scrambling method operating over Transport Stream packets is used, it may be necessary to use a 
stuffing mechanism to fill from the end of a section to the end of a packet so that any transitions between 
scrambled and unscrambled data occur at packet boundaries. 

In order to identify the CA streams which control the descrambling of the EIT data, a scrambled EIT 
schedule table shall be identified in the PSI. Servicejd value OxFFFF is allocated to identifying a 
scrambled EIT, and the program map section for this service shall describe the EIT as a private stream 
and shall include one or more CA_descriptors (defined in ISO/IEC 13818-1 [1]) which give the PID values 
and optionally, other private data to identify the associated CA streams. Servicejd value OxFFFF shall not 
be used for any other service. 

5.2 Table definitions 

The following subclauses describe the syntax and semantics of the different types of table. 

NOTE: The symbols and abbreviations, and the method of describing syntax used in this ETS 
are the same as those defined in sections 2.2 and 2.3 of ISO/IEC 13818-1 [1]. 
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5.2.1 Network Information Table (NIT) 

The NIT (see table 3) conveys Information relating to the physical organization of the 
multiplexes/Transport Streams (TS) carried via a given network, and the characteristics of the network 
itself. The combination of originaLnetworkJd and transport_streamJd allow each Transport Stream to be 
uniquely identified throughout the ETS application area. Networks are assigned individual networkjd 
values, which serve as unique identification codes for networks. The allocation of these codes may be 
found in ETR 162 [6]. In the case that the NIT is transmitted on the network on which the 
Transport Stream was originated, the networkjd and the originaLnetworkJd shall take the same value. 

Guidelines for the processing of Service Information at transitions between delivery media boundaries, 
e.g. from satellite to cable or SMATTER systems, can be found in ETR 21 1 [7]. 

IRD s may be able to store the NIT information in non-volatile memory in order to minimise the access tim e 
when switchinp between channels ("channel hopping"). It is also possible to transmit a Ni l' tor otngT 
networks in addition to the antnal n etwork. Differentiat ion between the Nl I tor the actual network and ine^ 
Ni I tor other networks is achieved using different tablejd values (see table 2). 

The NIT shall be segmented into networkjnformation_sections using the syntax of table 3. Any sections 
forming part of an NIT shall be transmitted in Transport Stream packets with a PID value of 0x0010. 
Any sections of the NIT which describe the actual network (that is, the network of which the 
Transport Stream containing the NIT is a part) shall have the tablejd value 0x40 with the networkjd field 
taking the value assigned to the actual network in ETR 162 [6]. Any sections of an NIT which refer to a 
network other than the actual network shall take a tablejd value of 0x41 and the networkjd shall take the 
value allocated to the other network in ETR 162 [6]. 



Table 3: Network information section 



Syntax 


No. 
of bits 


Identifier 


networkJnformation_section(){ 






tablejd 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


reserved future use 


1 


bslbf 


reserved 


2 


bslbf 


sectionjength 


12 


uimsbf 


networkjd 


16 


uimsbf 


reserved 


2 


bslbf 


version number 


5 


uimsbf 


current next indicator 


1 


bslbf 


section number 


8 


uimsbf 


last section number 


8 


uimsbf 


reservedjuture_use 


4 


bslbf 


network__descriptors_length 


12 


uimsbf 


for(i=0;i<N;i++){ 






descriptorO 






1 






reserved Juture_use 


4 


bslbf 


transport_streamJoop_length 


12 


uimsbf 


for{i=0;i<N;i++){ 






transport_streamJd 


16 


uimsbf 


originaLnetworkJd 


16 


uimsbf 


reserved Juture_use 


4 


bslbf 


transport_descriptors_length 


12 


uimsbf 


for{i=0;i<N;i++){ 






descriptorO 


















CRC 32 


32 


rpchof 


} 
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Semantics for the network information section: 
table_id: See table 2. 

section_syntax_indicator: The section_syntaxJndicator is a 1-bit field which shall be set to "1 

sectionjength: This is a 12-bit field, the first two bits of which shall be "00". It specifies the number 
of bytes of the section, starting immediately following the sectionjength field and including the CRC. 
The sectionjength shall not exceed 1 021 so that the entire section has a maximum length of 
1 024 bytes. 

network Jd: This is a 16-bit field which serves as a label to identify the delivery system, about which the 
NIT informs, from any other delivery system. Allocations of the value of this field are found in ETR 162 [6]. 

verslon_number: This 5-bit field is the version number of the subjable. The version_number shall be 
incremented by 1 when a change in the information carried within the subjable occurs. When it reaches 
value 31. it wraps around to 0. When the current_nextJndicator is set to "1", then the version_number 
shall be that of the currently applicable subjable defined by the tablejd and networkjd. When the 
current_nextJndicator is set to "0", then the version_number shall be that of the next applicable 
subjable defined by the tablejd and networkjd. 

current_nextJndicator: This 1-bit indicator, when set to "1" indicates that the subjable is the currently 
applicable subjable. When the bit is set to "0", it indicates that the subjable sent is not yet applicable 
and shall be the next subjable to be valid. 

section_number: This 8-bit field gives the number of the section. The section_number of the first section 
in the subjable shall be "0x00". The section_number shall be incremented by 1 with each additional 
section with the same tablejd and networkjd. 

last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the 
highest section_number) of the sub_table of which this section is part. 

network_descriptorsJength: This 12-bit field gives the total length in bytes of the following network 
descriptors. 

transport_streamJoopJength: This is a 12-bit field specifying the total length in bytes of the 
Transport Stream loops that follows, ending immediately before the first CRC-32 byte. 

transport_streamJd: This is a 16-bit field which serves as a label for identification of this 
Transport Stream from any other multiplex within the delivery system. 

originaLnetworkJd: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system. 

transport_descriptorsJength: This is a 12-bit field specifying the total length in bytes of 
Transport Stream descriptors that follow. 

CRC__32: This is a 32-bit field that contains the CRC value that gives a zero output of the registers in the 
decoder defined in annex B after processing the entire section. 

5-2.2 Bouquet Association Table (BAT) 

The BAT (see table 4) provides information regarding bouquets. A bouquet is a collection of services, 
which may traverse the boundary of a network. 

The BAT shall be segmented into bouquet_association_sections using the syntax of table 4. Any sections 
forming part of a BAT shall be transmitted in Transport Stream packets with a PID value of 0x0011. 
The sections of a BAT subjable describing a particular bouquet shall have the bouquetjd field taking the 
value assigned to the bouquet described in ETR 162 [6]. All BAT sections shall take a tablejd value of 
0x4A. 
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Table 4: Bouquet association section 



3yntax 


No 

of bits 


IHpntif ipr 

IVICI 1 LI 1 Id 


bouQuet assopiation sectionHf 






tablp id 


3 


uimsbf 


Ov^v-riivi 1 oyi lidA II ivju-^ciivi 


1 


bslbf 


rpQprv/oH fi iti irp li^P 
1 Cod vcu, ,itjiuic, uoo 


1 


bslbf 


rpcorv/oH 

1 Cod WvJ 




h(;ibf 

UOlUI 


Od^llUI l_id IVjtl 1 


1? 


1 limQhf 

UN 1 lOL/l 


hrti ini lof tH 


1fi 
i \J 


Ull 1 lOUl 


i cod VCvJ 




hqibf 

L/OIUI 


vpr^ion ni irnhpr 

VCI Ol^^l 1 1 iUI 1 lUKSl 




Ull 1 loui 


f*iirrpnt nPYt inHip?itr*r 

OUIIdll 1 ICAl II IUIl^C3.ll^l 


1 


UOlUI 


^pptinn ni imhpr 

OC^^IIWI 1 IILIIIIUd 


Q 
O 


1 limchf ^ 
Ull 1 loUi 


lf)Qt c&r*tif^n ni imhor 

Idol Od^llCI 1 1 ILII 1 ILfd 


Q 
O 


Ull 1 toUl 


icodVcu luiufc Uoc 


A 


hclhf 
UolUI 


Ui^ULjUcl ^UcoOl l|JlUlo iciiyui 




uimsuT 


fnr/i — n'i^M'ia-j.\/ 






UcoLriipilJr^^ - 






\ 
I 






rocorv/oH f i iti iro i ico 
1 Cod VcVJ lUlLiic Uoc 


A 


hclhf 
UolUI 


irancri/^rt of room lrtrtr\ lonnth 
11 dl lopL/l I oil Cdl 1 1 l(JL/p ifcJI ly If 1 


1 c. 


Ull TloUI 


lUi ^1 — U,l<.IN,l-r+^\ 






¥ i*o I'* r+ e» f ire% rm i 

I rdnspoii_sirearTi_ia 


1 D 


I 1 iffxe^ I^F 

uimsDr 


ui lyif idi 1 iciworiv lu 


1 D 


uimsDi 


rpoprvpri ft iti JTP 1 i*?p 


4 


bslbf 


transport_descriptors_length 


12 


uimsbf 


for(i=0;i<N;j++){ 






descriptorO 












) 






CRC 32 


32 


rpchof 


> 







Semantics for the bouquet association section: 



tablejd: See table 2. 

sectlon_syntax_indicator: The section_syntax_indicator is a 1-bit field which shall be set to "1". 

section Jength: This is a 12-bit field, the first two bits of which shall be "GO". It specifies the number 
of bytes of the section, starting Immediately following the sectionjength field and including the CRC. 
The section Jength shall not exceed 1 021 so that the entire section has a maximum length of 
1 024 bytes. 

bouquet Jd: This is a 16-bit field which serves as a label to identify the bouquet. Allocations of the value 
of this field are found in ETR 162 [6]. 

version_number: This 5-bit field is the version number of the sub_table. The version_number shall be 
incremented by 1 when a change in the information carried within the sub_table occurs. When it reaches 
value 31, it wraps around to 0. When the current_nextJndicator is set to "1", then the version_number 
shall be that of the currently applicable sub_table defined by the tablejd and bouquetjd. When the 
current_nextJndicator is set to "0", then the version_number shall be that of the next applicable 
sub Jable defined by the tablejd and bouquet_id. 

current_nextJndlcator: This 1 -bit indicator, when set to "1" indicates that the sub Jable is the currently 
applicable subjable. When the bit is set to "0", it indicates that the subjable sent is not yet applicable 
and shall be the next subjable to be valid. 
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section„number: This 8-bit field gives the number of the section. The section_nunnber of the first section 
in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each additional 
section with the same tablejd and bouquetjd. 

last_section_n umber: This 8-bit field specifies the number of the last section (that is, the section with the 
highest section_number) of the sub_table of which this section is part. 

bouquet_descrlptorsJength: This 12-bit field gives the total length in bytes of the following descriptors. 

transport_stream_loop_length: This is a 12-bit field specifying the total length in bytes of the 
Transport Stream loop that follows. 

transport_stream_id: This is a 16-bit field which serves as a label for identification of this 
Transport Stream from any other multiplex within the delivery system. 

originaI_network_id: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system. 

transport_descriptors_length; This is a 12-bit field specifying the total length in bytes of 
Transport Stream descriptors that follows. 

CRC_32: This is a 32-bit field that contains the CRC value that gives a zero output of the registers in the 
decoder defined in annex B after processing the entire private section. 

5,2.3 Service Description Table (SDT) 

Each sub_table of the SDT (see table 5) shall describe services that are contained within a particular 
Transport Stream. The services may be part of the actual Transport Stream or part of other 
Transport Streams, these being identified by means of the tablejd (see table 2). 

The SDT shall be segmented into service_description_sections using the syntax of table 5. Any sections 
forming part of an SDT shall be transmitted in Transport Stream packets with a PID value of 0x0011. 
Any sections of the SDT which describe the actual Transport Stream (that is, the Transport Stream 
containing the SDT) shall have the tablejd value 0x42, and any sections of an SDT which refer to a 
Transport Stream other than the actual Transport Stream shall take a tablejd value of 0x46. 
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Table 5: Service description section 



Syntax 


No. 
of bits 


Identifier 


service_description . sectionOf 






table id 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


reserved future use 


1 


bslbf 


reserved 


2 


bslbf 


sectionjength 


12 


uimsbf 


trans port_stream_id 


16 


uimsbf 

^Ji III 1^ In/ I 


reserved 


2 


bslbf 


version number 


5 


uimsbf 


current_next_indicator 


1 


bslbf 


section_number 


8 


uimsbf 

\J III 1 Wlh/ 1 


last_section_number 


8 


uimsbf 


o rig 1 nal_netwo rk_id 


16 


uimsbf 


reserved_future_use 


8 


bslbf 


for (i=0;i<N;i++){ 






service id 


16 


iiim^hf 

U III ioi>yi 


reserved future use 


5 


bslbf 


EIT_schedule_flag 


1 


bslbf 


EIT_present_following_flag 


-| 


bslbf 


running status 


3 


Ijlll 1 lOL/l 


free CA mode 


1 


bslbf 


descrlptorsjoopjength 


12 


uimsbf 


for (j=0;j<N;i++)( 






descriptorO 






> 






) 






CRC 32 


32 


rpchof 


} 







Semantics for the service description section: 



tablejd: See table 2. 

section_syntaxJndicator: The section_syntax_indicator is a 1-blt field which shall be set to "1". 

sectionjength: This is a 12-bit field, the first two bits of which shall be "GO". It specifies the number 
of bytes of the section, starting immediately following the sectionjength field and including the CRC, 
The sectionjength shall not exceed 1 021 so that the entire section has a maximum length of 
1 024 bytes. 

transport_streamJd: This is a 16-bit field which serves as a label for identification of the 
Transport Stream, about which the SDT informs, from any other multiplex within the delivery system. 

versIon_number: This 5-bit field is the version number of the subjable. The version_number shall be 
incremented by 1 when a change in the information carried within the subjable occurs. When it reaches 
value "31", it wraps around to "0". When the current_nextJndicator is set to "1", then the version_number 
shall be that of the currently applicable subjable. When the current_nextJndicator is set to "0", then the 
version_number shall be that of the next applicable subjable. 

current_nextJndicator: This 1-bit indicator, when set to "1" indicates that the subjable is the currently 
applicable subjable. When the bit is set to "0", it indicates that the subjable sent is not yet applicable 
and shall be the next subjable to be valid. 

section_number: This 8-bit field gives the number of the section. The section_number of the first section 
in the subjable shall be "0x00". The section_number shall be incremented by 1 with each additional 
section with the same tablejd, transport_streamJd, and originaLnetworkJd. 
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last_section_number: This 8-bit field specifies the number of the last seetion (that is, the section with the 
highest section_n umber) of the sub_table of which this section is part. 

original_network_id: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system. 

service_id: This is a 16-bit field which serves as a label to identify this service from any other service 
within the Transport Stream. The servicejd is the same as the program_number in the corresponding 
program_map_section. 

EIT_schedule_flag: This is a 1-bit field which when set to "1" indicates that EIT schedule information for 
the service is present in the current Transport Stream (see Guidelines on Implementation of Service 
Information (see annex D: bibliography) for information on maximum time interval between occurrences of 
an EIT schedule sub__table). If the flag is set to 0 then the EIT schedule information for the service should 
not be present in the Transport Stream, 

EIT_present_following_f!ag: This is a 1 -bit field which when set to "1 " indicates that 
EIT_present_following information for the service is present in the current Transport 
Stream (see Guidelines on Implementation of Service Information (see annex D: bibliography) for 
information on maximum time interval between occurrences of an EIT present/following sub_table). If the 
flag is set to 0 then the EIT present/following information for the service should not be present in the 
Transport Stream, 

running_status: This is a 3-bit field indicating the status of the service as defined in table 6. 



Table 6: SDT running_status 



Value 


Meaning 


0 


undefined 


1 


not running 


2 


starts in a few seconds (e.g. for video recording) 


3 


pausing 


4 


running 


5 to 7 


reserved for future use 



free_CA_mode: This 1-bit field, when set to "0" indicates that all the component streams of the service 
are not scrambled. When set to "1" it indicates that access to one or more streams may be controlled by a 
CA system. 

descriptors_loop_length: This 12-bit field gives the total length in bytes of the following descriptors. 

CRC_32: This is a 32-bit field that contains the CRC value that gives a zero output of the registers in the 
decoder defined in annex B after processing the entire section. 

5.2.4 Event Information Table (EIT) 

The EIT (see table 7) provides information in chronological order regarding the events contained within 
each service. Four classifications of EIT have been identified, distinguishable by the use of different 
table Jds (see table 2): 

1 ) actual Transport Stream, present/following event information = table Jd = "0x4E*'; 

2) other Transport Stream, present/following event infomnation = tablejd = •'0x4F"; 

3) actual Transport Stream, event schedule information = tablejd = "0x50" to "OxSF"; 

4) other Transport Stream, event schedule information = tablejd = "0x60" to "OxBF". 

The present/following table shall contain only information pertaining to the present event and the 
chronologically following event carried by a given service on either the actual Transport Stream or another 
Transport Stream, except in the case of a Near Video On Demand (NVOD) reference service where it 
may have more than two event descriptions. The event schedule tables for either the actual 
Transport Stream or other Transport Streams, contain a list of events, in the form of a schedule, namely, 
including events taking place at some time beyond the next event. The EIT schedule tables are optional. 
The event information shall be chronologically ordered. 
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The EIT shall be segmented into eventJnformation_sections using the syntax of table 7. Any sections 
forming part of an EIT shall be transmitted in Transport Stream packets with a PID value of 0x0012. 



Table 7: Event information section 



Syntax 

— — 


No- of 
Bits 


Identifier 


Event_lnformation_section()( 






table_ia 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


reserved_f utu re_use 


1 


bslbf 


reserved 


2 


bslbf 


section_length 


12 


uimsbf 


service_id 


16 


uimsbf 


reserved 


2 


bslbf 


version_number 


5 


uimsbf 


current„next_indlcator 


1 


bslbf 


section_number 


8 


uimsbf 


last_section_number 


8 


uimsbf 


transport_stream_id 


16 


uimsbf 


original_network_id 


16 


uimsbf 


segment_last_section_number 


8 


uimsbf 


last„tablejd 


8 


uimsbf 


for(i=0;i<N;j++){ 






event id 


16 


uimsbf 


start_time 


40 


bslbf 


Quraiion 


24 


uimsbf 


running_status 


3 


uimsbf 


free_CA_mode 


1 


bslbf 


descriptors loop length 


12 


uimsbf 


for(i=0;i<N;i++)f 






descriptorO 






} 






) 






CRC 32 


32 


rpchof 









Semantics for the event information section: 



table_id: See table 2. 

section_syntaxJndicator: The section_syntaxJndicator is a 1-bit field which shall be set to "1". 

section Jength: This is a 12-bit field. It specifies the number of bytes of the section, starting immediately 
following the sectionjength field and including the CRC. The sectionjength shall not exceed 4 093 so 
that the entire section has a maximum length of 4 096 bytes. 

servicejd: This is a 16-bit field which serves as a label to identify this service from any other service 
within a Transport Stream. The servicejd is the same as the program_number in the corresponding 
program_map_section. 
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version_number: This 5-bit field is the version number of the sub__table. The version_number shall be 
incremented by 1 when a change in the information carried within the sub_table occurs. When it reaches, 
value 31, it wraps around to 0. When the current_next__indicator is set to "1", then the version_number 
shall be that of the currently applicable sub_table defined by the tablejd and service_id. When the 
current_nextJndicator is set to "0", then the version_number shall be that of the next applicable 
sub_table defined by the tablejd and servicejd. 

current_next_indicator: This 1-bit indicator, when set to "1" indicates that the sub_table is the currently 
applicable sub_table. When the bit is set to "0", it indicates that the sub_table sent is not yet applicable 
and shall be the next sub_table to be valid. 

section_number: This 8-bit field gives the number of the section. The section_number of the first section 
in the sub_table shall be "0x00". The section_n umber shall be incremented by 1 with each additional 
section with the same tablejd, servicejd, transport_streamJd, and originaLnetworkJd. In this case, the 
subjabie may be structured as a number of segments. Within each segment the section_number shall 
increment by 1 with each additional section, but a gap in numbering is permitted between the last section 
of a segment and the first section of the adjacent segment. 

last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the 
highest section_n umber) of the subjabie of which this section is part. 

transport_streamJd: This is a 16-bit field which serves as a label for identification of the 
Transport Stream, about which the EIT informs, from any other multiplex within the delivery system. 

originaLnetworkJd: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system. 

segmentJast_section_number: This 8-bit field specifies the number of the last section of this segment 
of the subjabie. For subjables which are not segmented, this field shall be set to the same value as the 
last_section_number field. 

Iast_tablejd: This 8-bit field identifies the last tablejd used (see table 2). If only one table is used this is 
set to the tablejd of this table. The chronological order of information is maintained across successive 
tablejd values. 

event Jd: This 16-bit field contains the identification number of the described event (uniquely allocated 
within a service definition). 

start_time: This 40-bit field contains the start time of the event in Universal Time, Co-ordinated (UTC) 
and Modified Julian Date (MJD) (see annex C). This field is coded as 16 bits giving the 16 LSBs of MJD 
followed by 24 bits coded as 6 digits in 4-bit Binary Coded Decimal (BCD). If the start time is undefined 
(e.g. for an event in a NVOD reference service) all bits of the field are set to "1 

EXAMPLE 1 : 93/1 0/1 3 1 2:45:00 is coded as "0xC0791 24500". 

duration: A 24-bit field containing the duration of the event in hours, minutes, seconds. 

format: 6 digits, 4-bit BCD = 24 bit. 

EXAMPLE 2: 01:45:30 is coded as "0x014530". 

running_status: This is a 3-bit field indicating the status of the event as defined in table 6, 

free_CA_mode: This 1-bit field, when set to "0" indicates that all the component streams of the event are 
not scrambled. When set to "1" it indicates that access to one or more streams is controlled by 
a CA system. 

descriptorsjoopjength: This 12-bit field gives the total length in bytes of the following descriptors. 

CRC_32: This is a 32-bit field that contains the CRC value that gives a zero output of the registers in the 
decoder defined in annex B after processing the entire private section. 
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5.2.5 Time and Date Table (TDT) 

The TDT (see table 8) carries only the UTC-time and date information. 

The TDT shall consist of a single section using the syntax of table 8. This TDT section shall be transmitted 
in Transport Stream packets with a PID value of 0x0014, and the table_ld shall take the value 0x70. 



Table 8: Time and date section 



Syntax 


No. 
of bits 


Identifier 


time„date_section(){ 






table id 


8 


uimsbf 


section_syntaxJndicator 


1 


bslbf 


reserved_future_use 


1 


bslbf 


reserved 


2 


bslbf 


section_length 


12 


uimsbf 


UTC time 


40 


bslbf 


} 







Semantics for the time and date section: 



table Jd: See table 2. 

section_syntax_indicator: This is a one-bit indicator which shall be set to "0". 

section_length: This is a 12-bit field, the first two bits of which shall be "00", It specifies the number 
of bytes of the section, starting immediately following the sectionjength field and up to the end of the 
section. 

UTC_time: This 40-bit field contains the current time and date in UTC and MJD (see annex C). This field 
is coded as 16 bits giving the 16 LSBs of MJD followed by 24 bits coded as 6 digits in 4-bit BCD. 

EXAMPLE: 93/1 0/1 3 1 2:45:00 is coded as "0xC0791 24500". 

5.2.6 Time Offset Table (TOT) 

The TOT (see table 9) carries the UTC-time and date information and local time offset. The TOT shall 
consist of a single section using the syntax of table 9. This TOT section shall be transmitted in 
Transport Stream packets with a PID value of 0x0014, and the tabiejd shall take the value 0x73. 



Table 9: Time offset section 



Syntax 


No- 
of bits 


Identifier 


time_offset_section(){ 






table id 


8 


uimsbf 


section_svntax_indicator = 0 


1 


bsibf 


reserved_future_use 


1 


bslbf 


reserved 


2 


bslbf 


sectionjength 


12 


uimsbf 


UTC_time 


40 


bslbf 


reserved 


4 


bslbf 


descriptorsjoopjength 


12 


uimsbf 


for(i=0;i<N;i++){ 






descriptorO 






> 






CRC 32 


32 


rpchof 


} 
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Semantics for the time offset section: 
tablejd: See table 2. 

section_syntax_indicator: This is a one-bit indicator which shall be set to "0". 

section_length: This is a 12-blt field, the first two bits of which shall be "00". It specifies the number 
of bytes of the section, starting immediately following the sectionjength field and up to the end of the 
section. 

UTC_time: This 40-bit field contains the current time and date in UTC and MJD (see annex C). This field 
is coded as 16 bits giving the 16 LSBs of MJD followed by 24 bits coded as 6 digits in 4-bit BCD. 

EXAMPLE: 93/10/13 12:45:00 is coded as "0x0079124500", 

descriptorsjoopjength: This 12-bit field gives the total length in bytes of the following descriptors. 

CRC_32: This is a 32-bit field that contains the CRC value that gives a zero output of the registers in the 
decoder defined in annex B after processing the entire private section. 

5,2.7 Running Status Table (RST) 

The RST (see table 10) allows accurate and rapid updating of the timing status of one or more events. 
This may be necessary when an event starts early or late due to scheduling changes. The use of a 
separate table enables fast updating mechanism to be achieved. 

The RST shall be segmented into running_status_sections using the syntax of table 10. Any sections 
forming part of an RST shall be transmitted in Transport Stream packets with a PID value of 0x0013, and 
the tablejd shall take the value 0x71 . 



Table 10: Running status section 



Syntax 


No. 
of bits 


Identifier 


running_status_section(){ 






table id 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


reserved future use 


1 


bslbf 


reserved 


2 


bslbf 


sectionjength 


12 


uimsbf 


for (i=0;i<N;i-i-+){ 






transport_stream_id 


16 


uimsbf 


originaLnetworkJd 


16 


uimsbf 


service id 


16 


uimsbf 


event id 


16 


uimsbf 


reserved Juture_use 


5 


bslbf 


running status 


3 


uimsbf 


) 






} 







Semantics for the running status section: 



tablejd: See table 2. 

sectlon_syntax Jndicator: This is a one-bit indicator which shall be set to "0". 

sectionjength: This is a 12-bit field, the first two bits of which shall be "00". It specifies the number 
of bytes of the section, starting immediately following the sectionjength field and up to the end of the 
section. The sectionjength shall not exceed 1 021 so that the entire section has a maximum length of 
1 024 bytes. 
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transport_stream_id: This is a 16-bit field which serves as a label for identification of the 
Transport Stream, about which the RST informs, from any other multiplex within the delivery system. 

originaLnetwork_id: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system. 

service_id: This is a 16-bit field which serves as a label to identify this service from any other service 
within the Transport Stream. The servicejd is the same as the program_number in the corresponding 
program_map_section. 

event_id: This 16-bit field contains the identification number of the related event. 
running_status: This is a 3-bit field indicating the status of the event, as defined in table 6. 
5.2.8 Stuffing Table (ST) 

The purpose of this section (see table 11) is to invalidate existing sections at a delivery system boundary 
e.g. at a cable head-end. When one section of a sub_table is overwritten, then all the sections of that 
sub_table shall also be overwritten (stuffed) in order to retain the integrity of the section_number field. 



Table 11: Stuffing section 



Syntax 


No. 
of bits 


Identifier 


stuff ing_section(){ 






table id 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


reserved future use 


1 


bslbf 


reserved 


2 


bslbf 


sectionjength 


12 


uimsbf 


for (i=0;i<N;i++){ 






data byte 


8 


uimsbf 















Semantics for the stuffing section: 



tablejd: This 8-bit field shall take the value "0x72" according to table 2. 
section_syntaxJndicator: This 1 -bit field may take either the value "1 " or "0". 

sectionjength: This is a 12-bit field. It specifies the number of bytes of the section, starting immediately 
following the sectionjength field and up to the end of the section. The sectionjength shall not exceed 
4 093 so that the entire section has a maximum length of 4 096 bytes. 

data_byte: This 8-bit field may take any value and has no meaning. 
6 Descriptors 

This clause describes the different descriptors that can be used within the SI (for further information, see 
annex D: bibliography). 

6.1 Descriptor identification and location 

Table 12 lists the descriptors defined within this ETS, giving the descriptors-tag values and the intended 
placement within the SI tables. This does not imply that their use in other tables is restricted. 
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Table 12: Possible locations of descriptors 



Descriptor 


Tag value 


NIT 


BAT 


SDT 


BIT 


TOT 


PMT 


network_name„descriptor 


0x40 




_ 










service Jist_descriptor 


0x41 


* 


♦ 


_ 








stuffinq_descriptor 


0x42 


* 


* 


* 


* 






satellite_delivery_system_descriptor 


0x43 


♦ 


_ 










cable_deIiverv_svstem_descriptor 


0x44 


* 












reserved for future use 


0x45 


_ 


_ 










reserved for future use 


0x46 














bouquet_name_descriptor 


0x47 




* 


* 








service_descriptor 


0x48 






* 








country_availabi!ity_descriptor 


0x49 






* 








linkage_descriptor 


0x4A 


* 


* 


* 


* 






NVOD_reference_descriptor 


0x4B 






* 








time_shifted_service_descriptor 


0x4C 






* 








short_event_descriptor 


0x4D 








* 






extended_event_descriptor 


0x4E 








* 






tinne_shifted_event„descriptor 


0x4F 








* 






component_descriptor 


0x50 








* 






mosaic_descriptor 


0x51 












* 


stream_ldentifier_descriptor 


0x52 












* 


CA_identifier„descriptor 


0x53 




* 


* 


* 






content_descriptor 


0x54 








* 






parentaI_rating_descriptor 


0x55 








* 






teletext_descriptor 


0x56 












* 


telephone_descriptor 


0x57 






* 








local_time_offset_descriptor 


0x58 










* 




subtitling_descriptor 


0x59 












* 


terrestrial_deIivery_system_descriptor 


0x5A 


* 












mu!tilingual_network_name_descriptor 


0x5B 


* 












multilinguaLbouquet_name_descriptor 


0x5C 




* 










multilingual_service_name__descrlptor 


0x5D 


_ 


_ 




_ 






multilinguaLcomponent_descriptor 


0x5E 








* 






private_data_specifier_descriptor 


0x5F 


* 




* 


* 






service_move_descriptor 


0x60 












* 


short_smoothing_buffer_descriptor 


0x61 








* 






reserved for future use 


0x62 to 0x7F 














user defined 


0x80 to OxFE 














forbidden 


OxFF 















Possible location. 



6.2 Descriptor coding 

When the construct "descriptor ()" appears in the sections of subclause 5.2. this indicates that zero or 
more of the descriptors defined within this subclause shall occur. 

The following semantics apply to all the descriptors defined in this subclause. 

descriptor_tag: The descriptor tag is an 8-bit field which identifies each descriptor. Those values with 
MPEG-2 normative meaning are described in ISO/IEC 13818-1 [1]. The values of descriptor_tag are 
defined in table 12. 

descriptorjength: The descriptor length is an 8-bit field specifying the total number of bytes of the data 
portion of the descriptor following the byte defining the value of this field. 
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6.2.1 Bouquet name descriptor 

The bouquet name descriptor provides the bouquet name in text form, see table 13. 



Table 13: Bouquet name descriptor 



Syntax 


No. of 
Bits 


Identifier 


bouquet_name_descrlptor(){ 






descriptor„tag 


8 


uimsbf 


descriptorjength 






for(i=0;i<N;i++)f 


8 


uimsbf 


char 






) 


8 


uimsbf 


} 







Semantics for the bouquet name descriptor: 



char: This is an 8-bit field, a sequence of which conveys the name of the bouquet about which the 
BAT sub_table informs. Text information is coded using the character sets and methods described in 
annex A. 

6.2.2 CA Identifier descriptor 

The CA identifier descriptor (see table 14) indicates whether a particular bouquet, service, event or 
component is associated with a conditional access system and identifies the CA system type by means of 
the CA_system_id. 



Table 14: CA identifier descriptor 



Syntax 


No. 
of bits 


Identifier 


CAJdentifier_descriptor()( 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i++)f 






CA system id 


16 


uimsbf 


) 






} 







Semantics for the CA identifier descriptor: 



CA_systemJd: This 16-bit field identifies the CA system. Allocations of the value of this field are found in 
ETR 162 [6]. 

6.2-3 Component descriptor 

The component descriptor identifies the type of component stream and may be used to provide a text 
description of the elementary stream (see table 15). 
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Table 15: Component descriptor 



1 1 LdA. 


iMO. 
rxf Kite 


Identifier 


pomnnnpnt rip^rrintorrW 






HpQrrintnr t?*n 


Q 
O 


— 

uimsbf 


Hficpriritrir Ipnnth 


O 

o 


UlmSuT 


rcaofarv/oH f i iti iro i ico 
1 COCI V t?\J 1 LIIUI C UoC? 




DSIDT 


stream„content 


4 


uim<?hf 

Uil 1 lOlafl 


component_type 


8 


uimsbf 


component_tag 


8 


uimsbf 


ISO_639Janguage_code 


24 


bslbf 


for (i=0;i<N;i++){ 






text char 


8 


uimsbf 















Semantics for the component descriptor: 



stream_content: This 4-bit field specifies the type (video, audio, or EBU-data) of stream. The coding of 
this field is specified in table 1 6 below. 

component_type: This 8-bit field specifies the type of the video, audio or EBU-data component. 
The coding of this field is specified in table 16 below. 

component_tag: This 8-bit field has the same value as the component_tag field in the stream identifier 
descriptor (if present in the PSI program map section) for the component stream. 

ISO_639_language_code: This 24-bit field identifies the language of the component (in the case of audio 
or EBU-data) and of the text description which may be contained in this descriptor. 
The ISO_639Janguage_code contains a 3-character code as specified by ISO 639 Part 2 [3]. 
Both ISO 639.2/B and ISO 639.2yT may be used. Each character is coded into 9 bits according to 
ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'01 10 01 10 01 1 1 0010 01 10 010V. 

text^char: This is an 8-bit field. A string of "text_char" fields specifies a text description of the component 
stream. Text information is coded using the character sets and methods described in annex A. 
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Table 16: stream_content and component__type 



Stream_content 


Connponent_type 


Description 


0x00 


0x00 to OxFF 


reserved for future use 


0x01 


0x00 


reserved for future use 


0x01 


0x01 


video, 4:3 aspect ratio 


0x01 


0x02 


video. 16'9 asoect ratio with oan vectors 


0x01 


0x03 


video, 1 6:9 aspect ratio without pan vectors 


0x01 


0x04 


video. > 16*9 asoect ratio 


0x01 


0x05 to OxFF 


reserved for future use 


0x02 


0x00 


reserved for future use 


0x02 


0x01 


audio, sinale mono channel 


0x02 


0x02 


audio, dual mono channel 


0x02 


0x03 


audio, stereo (2 channel) 


0x02 


0x04 


audio, multi-linaual multi-channel 

%AUX^l%^f t 1 llrtllLI til |\pi|wl^4^lf 1 1 I^JIVI Idl M l^^l 


0x02 


0x05 


audio surround sound 


0x02 


0x06 to 0x3F 


reserved for future use 


0x02 


0x40 


audio descrintion for thp \/i<>iiAli\/ imnairfaH 


0x02 


0x41 


audio for the hard of hearina 


0x02 


0x42 to OxAF 


reserved for future use 


0x02 


OxBO to OxFE 


user-defined 


0x02 


OxFF 


reserved for future use 


0x03 


0x00 


resen/ed for future I j<?p 


0x03 


0x01 


FBU Tplpfpxt <;uhtitlp<; 


0x03 


0x02 


associated EBU Teletext 


0x03 


0x03 to OxOF 


r^Qorv/oH for fi iti iro i ico 
1 cod VOVJ l\JI lUlUIC uoo 


0x03 


0x10 


DVB subtitles (normal) with no monitor aspect ratio criticality 


wo 


KJa. I 1 


l/vd suDTiiies (normal; lor oispiay on 4.o aspect ratio monitor 


0x03 


0x12 


DVB subtitles (normal) for display on 16:9 aspect ratio monitor 


v/AUO 


UX 1 O 


DVB subtitles (normal) for display on 2.21:1 aspect ratio monitor 


0x03 


0x14 to 0x1 F 


reserved for future use 


UXUo 


ux^o 


DVB subtitles (for the hard of heanng) with no monitor aspect ratio 
criticality 


KJaXJO 


UX^l 


DVB subtitles (for the hard of hearing) for display on 4:3 aspect ratio 
monitor 


0x03 


0x22 


DVB subtitles (for the hard of hearing) for display on 16:9 aspect 
ratio monitor 


0x03 


0x23 


DVB subtitles (for the hard of hearing) for display on 2.21 :1 aspect 
ratio monitor 


0x03 


0x24 to OxFF 


reserved for future use 


0x04 to OxOB 


0x00 to OxFF 


reserved for future use 


OxOC to OxOF 


0x00 to OxFF 


user defined 
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6.2.4 Content descriptor 

The intention of the content descriptor (see table 17) is to provide classification information for an event. 



Table 17: Content descriptor 



Syntax 


No. 
of bits 


Identifier 


content_descriptor(){ 






descriptor_tacj 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;l++) { 






content_nibbleJeveI 1 


4 


uimsbf 


content_nibble level 2 


4 


uimsbf 


user_nibble 


4 


uimsbf 


user nibble 


4 


uimsbf 


) 






) 







Semantics of the content descriptor: 



content_nibbieJevel_1 : This 4-bit field represents the first level of a content identifier. This field shall be 
coded according to table 1 8. 

content„nibble_level_2: This 4-bit field represents the second level of a content identifier. This field shall 
be coded according to table 18. 

user_nibble: This 4-bit field is defined by the broadcaster. 
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Table 18: Content_nibble level 1 and 2 assignments 



Content_nibble_level_1 


Content nibble level 2 


Description 


0x0 


0x0 to OxF 


undefined content 






fVlovie/Drama: 


0x1 


0x0 


movie/drama (general) 


0x1 


0x1 


(jQ^QQ^jve/th filler 


0x1 


0x2 


adventure/western/war 


0x1 


0x3 


science fiction/fantasy/horror 


0x1 


0x4 


comedy 


0x1 


0x5 


soap/meiodrama/folkloric 


0x1 


0x6 


romance 


0x1 


0x7 


serious/classical/reiiqious/hlstorical movie/drama 


0x1 


0x8 


adult movie/drama 


0x1 


0x9 to OxE 


reserved for future use 


0x1 


OxF 


user defined 






News/Current affairs* 


0x2 


0x0 


news/current affairs (general) 


0x2 


0x1 


news/weather report 


0x2 


0x2 


news magazine 


0x2 


0x3 


documentary 


0x2 


0x4 


discussion/intervlew/debate 


0x2 


0x5 to OxE 


reserved for future use 


0x2 


OxF 


user defined 






Show/Game show: 


0x3 


0x0 . 


show/game show (general) 


0x3 


0x1 


game show/guiz/contest 


0x3 


0x2 


variety show 


0x3 


0x3 


talk show 


0x3 


0x4 to OxE 


reserved for future use 


0x3 


OxF 


user defined 








0x4 


0x0 


Qnnrt^ ( cjf^rtt^n^W 


0x4 


0x1 


o^cU'idi oVc^lllo \V^iyi 1 IfJIO Odlflcro, VVUliU OUp eiC/ 


0x4 


0x2 


0^\i/l LO 1 1 luvjCL^II ICO 


0x4 


0x3 


f noth;^ 1 1/Qor^f^P r 


0x4 


0x4 


tpnni^/Qni iJi^h 

Id II II0/0\^UC10I 1 


0x4 


0x5 




0x4 


0x6 


athletics 


0x4 


0x7 


motor sport 


0x4 


0x8 


water sport 


0x4 


0x9 


winter sports 


0x4 


OxA 


equestrian 


0x4 


OxB 


martial sports 


0x4 


OxC to OxE 


reserved for future use 


0x4 


OxF 


user defined 






Children's/Youth Droaramme*;- 


0x5 


0x0 


children's/vouth nronrammp^ ^npnArah 

Vfi iiiui ^1 1 Of y Vi/uil 1 ^,/vji dl 1 it 1 ICO Id dl / 


0x5 


0x1 


pre-school children's programmes 


0x5 


0x2 


entertainment programmes for 6 to 14 


0x5 


0x3 


entertainment programmes for 1 0 to 1 6 


0x5 


0x4 


informational/educational/school programmes 


0x5 


0x5 


cartoons/puppets 


0x5 


0x6 to OxE 


reserved for future use 


0x5 


OxF 


user defined 









(continued) 
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Table 18 (continued): Content_nibble level 1 and 2 assignments 



Content_nibbleJeveI_1 


Content_nibbIeJeveL2 


Description 






Music/Ballet/Dance: 


0x6 


0x0 


music/ballet/dance (Qeneral) 


0x6 


0x1 


rock/pop 


0x6 


0x2 


serious music/classical music 


0x6 


0x3 


folk/traditional music 


0x6 


0x4 


jazz 


0x6 


0x5 


musical/opera 


0x6 


0x6 


ballet 


0x6 


0x7 to OxE 


reserved for future use 


0x6 


OxF 


user defined 






Arts/CiJltiirf^ ^withmit miiQln\- 


0x7 


0x0 


cti la/uuiiui ^wiinoui music, Qeneraij 


0x7 


0x1 


poi 1 1 III ly dilo 


0x7 


0x2 


1 II IC7 di lo 


0x7 


0x3 


rolinir\n 
1 oiiy itji 1 


0x7 


0x4 


jupuiar cuiiure/iraaiiionai ans 


0x7 


0x5 


lilclcllUl o 


0x7 


0x6 


f ilm/pinAma 

III! 1 l/V^il Id 1 IcL 


0x7 


0x7 


experimental film/video 


0x7 


0x8 


broadcastinp/press 


0x7 


0x9 


new media 


0x7 


OxA 


arts/culture magazines 


0x7 


OxB 


fashion 


0x7 


OxC to OxE 


reserved for future use 


0x7 


OxF 


user defined 






Social/ Political issues/Economics: 


0x8 


0x0 


social/political issues/economics (general) 


0x8 


0x1 


magazines/reports/documentary 


0x8 


0x2 


economics/social advisory 


0x8 


0x3 


remarkable people 


0x8 


0x4 to OxE 


reserved for future use 


0x8 


OxF 


user defined 








0x9 


0x0 


euucation/science/racTuai topics (general) 


0x9 


0x1 


ridiure/animais/environment 


0x9 


0x2 


iccrinoioyy/naiurai sciences 


0x9 


0x3 


medicine/physiology/psychology 


0x9 


0x4 


foreign countries/expeditions 


0x9 


0x5 


social/spiritual sciences 


0x9 


0x6 1 


further education 


0x9 


0x7 


anguaqes 


0x9 


0x8 to OxE 1 


'eserved for future use 


0x9 


OxF [ 


jser defined 









(continued) 
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Table 18 (concluded): Content_nibble level 1 and 2 assignments 



Content_nibble_level_1 


Content_nibble_level_2 


Description 






Leisure hobbies: 


OxA 


0x0 


leisure hobbies (general) 


OxA 


0x1 


tourism/travel 


OxA 


0x2 


handicraft 


OxA 


0x3 


motoring 


OxA 


0x4 


fitness & health 


OxA 


0x5 


cooking 


OxA 


0x6 


advertisement/shopping 


OxA 


0x7 


gardening 


OxA 


0x8 to OxE 


resen/ed for future use 


OxA 


OxF 


user defined 






Special Characteristics . 


OxB 


0x0 


original language 


OxB 


0x1 


black & white 


OxB 


0x2 


unpublished 


OxB 


0x3 


live broadcast 


OxB 


0x4 to OxE 


reserved for future use 


OxB 


OxF 


user defined 


OxC to OxE 


0x0 to OxF 


reserved for future use 


OxF 


0x0 to OxF 


user defined 



6.2-5 Country availability descriptor 



In order to identify various combinations of countries efficiently, the descriptor may appear twice for each 
sen/ice, once giving a list of countries and/or groups of countries where the service is intended to be 
available, and the second giving a list of countries and/or groups where it is not. The latter list overrides 
the former list. If only one descriptor is used, which lists countries where the service is intended to be 
available, then it indicates that the service is not intended to be available in any other country. If only one 
descriptor is used, which lists countries where the service is not intended to be available, then it indicates 
that the service is intended to be available in every other country. If no descriptor is used, then it is not 
defined for which countries the service is intended to be available. See table 1 9. 



Table 19: Country availability descriptor 



Syntax 


No. 
of bits 


Identifier 


country_availability_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjenqth 


8 


uimsbf 


country_avaiIabilitv flag 


1 


bslbf 


reserved_future use 


7 


bsib 


for (i=0;i<N;i++)f 






country code 


24 


bsib 















Semantics for the country availability descriptor 



country_availability_flag: This 1-bit field indicates whether the following country codes represent the 
countries in which the reception of the service is intended or not. If country_avai!ability_fIag is set to "1" the 
following country codes specify the countries in which the reception of the service is intended. If set to "0", 
the following country codes specify the countries in which the reception of the service is not intended. 
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country_code: This 24-bit field Identifies a country using the 3-character code as specified in 
ISO 3166 [2]- Each character is coded into 8-bits according to ISO 8859-1 [5] and inserted in order into the 
24-bit field. In the case that the 3 characters represent a nunnber in the range 900 to 999, then 
country_code specifies a ETSI defined group of countries. These allocations are found in ETR 162 [6]. 

EXAiVIPLE: United Kingdom has 3-character code "GBR", which is coded as: 

'01 00 01 11 01 00 001 0 0101 001 0'. 

6.2.6 Delivery system descriptors 

The delivery system descriptors all have the same overall length of 13 bytes. This facilitates the 
interchange of these descriptors when a Transport Stream is transcoded from one delivery system to 
another, e.g. satellite to cable. 

6.2.6,1 Cable delivery system descriptor 

See table 20. 



Table 20: Cable delivery system descriptor 



Syntax 


No. 
of bits 


Identifier 


cabIe_deIivery_system_descriptor()( 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


frequency 


32 


bslbf 


reserved_future_use 


12 


bslbf 


PEG outer 


4 


bslbf 


modulation 


8 


bslbf 


symboLrate 


28 


bslbf 


PEG Inner 


4 


bslbf 


} 







Semantics for cable delivery system descriptor 



frequency: The frequency is a 32-bit field giving the 4-bit BCD values specifying 8 characters of the 
frequency value. Por the cable_delivery_system_descriptor, the frequency is coded in MHz, where the 
decimal occurs after the fourth character (e.g. 0312.0000 MHz). 

FEC_outer: The PEG_outer Is a 4-bit field specifying the outer PEG scheme used according to table 21: 



Table 21: Outer FEC scheme 



FEC_outer 


Description 


bit 3210 




0000 


not defined 


0001 


no outer PEG coding 


0010 


RS(204/188) 


0011 to 1111 


reserved for future use 



modulation: This is an 8-bit field. It specifies the modulation scheme used on a cable delivery system 
according to table 22: 
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Table 22: Modulation scheme for cable 



Modulation 


Description 


(hex) 




0x00 


not defined 


0x01 


16 QAM 


0x02 


32 QAM 


0x03 


64 QAM 


0x04 


128 QAM 


0x05 


256 QAM 


0x06 to OxFF 


reserved for future use 



symboLrate: The symboLrate is a 28-bit field giving the 4-bit BCD values specifying 7 characters of the 
symboLrate in Msymbol/s where the decimal point occurs after the third character (e.g. 027.4500). 

FECJnner: The FECJnner Is a 4-bit field specifying the inner FEC scheme used according to the 
following table 23: ^ 

Table 23: Inner FEC scheme 



FECJnner bit 
3210 


Description 


0000 


not defined 


0001 


1/2 con v. code rate 


0010 


2/3 conv. code rate 


0011 


3/4 conv. code rate 


0100 


5/6 conv. code rate 


0101 


7/8 conv. code rate 


1111 


no conv. coding 


0110 to 1110 


reserved for future use 



6.2.6-2 Satellite delivery system descriptor 

See table 24. 



Table 24: Satellite delivery system descriptor 



Syntax 



satellite_deliverv_svstem_descriptor()( 



No. 
of bits 



Identifier 



descriptor tap 



descriptorjength 
freguency 



8 



uimsbf 



8 



uimsbf 



32 



bslbf 



orbital_position 



west^east flag 



16 



bslbf 



polarization 



bslbf 



modulation 



bslbf 



symboLrate 
FECJnner 



bslbf 



28 



bslbf 
bslbf 



Semantics for satellite delivery system descriptor 

frequency: The frequency is a 32-bit field giving the 4-bit BCD values specifying 8 characters of the 
frequency value. For the sateIlite„delivery_system_descriptor the frequency is coded In GHz where the 
decimal point occurs after the third character (e.g. 01 1 .75725 GHz). 

orbitaLposltion: The orbital_position is a 16.bit field giving the 4-bit BCD values specifying 4 characters 

2n nioo J ^""f'*""" ^^9''^®^ where the decimal point occurs after the third character 
^e.g. 019,2 degrees). 
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west_east_flag: The west_east_flag is a 1-bit field Indicating if the satellite position is in the western or 
eastern part of the orbit. A value "0" indicates the western position and a value "1" indicates the eastern 
position. 

polarization: The polarization is a 2-bit field specifying the polarization of the transmitted signal. 
The first bit defines whether the polarization is linear or circular (see table 25). 



Table 25: Polarisation 



Polarisation 


Description 


00 


linear - horizontal 


01 


linear - vertical 


10 


circular - left 


11 


circular - right 



modulation: This is a 5-bit field. It specifies the modulation scheme used on a satellite delivery system 
according to table 26: 



Table 26: Modulation scheme for satellite 



Modulation bit 
4 3210 


Description 


0 0000 


not defined 


0 0001 


QPSK 


0 0010 to 11111 


reserved for future use 



symboLrate: The symboLrate is a 28-bit field giving the 4-bit BCD values specifying 7 characters of the 
symboLrate in Msymbol/s where the decimal point occurs after the third character (e.g. 027.4500), 

FECJnner: The FECJnner is a 4-bit field specifying the inner FEC scheme used according to table 23. 

6.2.7 Extended event descriptor 

The extended event descriptor provides a detailed text description of an event, which may be used in 
addition to the short event descriptor. More than one extended event descriptor can be associated to allow 
information about one event greater in length than 256 bytes to be conveyed. Text information can be 
structured into two columns, one giving an item description field and the other the item text. A typical 
application for this structure is to give a cast list, where for example the item description field might be 
"Producer" and the item field would give the name of the producer. 
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Table 27: Extended event descriptor 



Syntax 


No. 
of bits 


Identifier 


extended_event_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


desGriptor_number 


4 


uimsbf 


last_descriptor_number 


4 


uimsbf 


ISO_639_Ianguage_code 


24 


bslbf 


length_of_items 


8 


uimsbf 


for ( i=0;i<N;i++){ 






item_descriptionJength 


8 


uimsbf 


for (i=0;i<N;i++)f 






item description char 


8 


uimsbf 


} 






item_length 


8 


uimsbf 


for (i=:0;i<N;j-H-){ 






item char 


8 


uimsbf 








) 






text_length 


8 


uimsbf 


for (i=0;i<N;i++)( 






text char 


8 


uimsbf 


} 






} 







Semantics for the extended event descriptor: 



descriptor_number: This 4-bit field gives the number of the descriptor. It is used to associate information 
which cannot be fitted into a single descriptor. The descriptor_number of the first 
extended_event_descriptor of an associated set of extended_event_descriptors shall be "0x00". 
The descriptor_number shall be incremented by 1 with each additional extended_event_descriptor in this 
section. 

last_descrlptor_number: This 4-bit field specifies the number of the last extended_event_descriptor 
(that is, the descriptor with the highest value of descriptor_number) of the associated set of descriptors of 
which this descriptor is part. 

ISO_639_language_code: This 24-bit field identifies the language of the following text fields. 
The ISO_639Janguage_code contains a 3-character code as specified by ISO 639 Part 2 [3]. 
Both ISO 639.2/B and ISO 639.ZT may be used. Each character is coded into 9 bits according to 
ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre". which is coded as: 

'011001100111 oolooiiooior. 

length_ofJtems: This is an 8-bit field specifying the length in bytes of the following items. 

item_descriptionJength: This 8-bit field specifies the length in bytes of the item description. 

item_description_char: This is an 8-bit field. A string of "item_description_char" fields specify the item 
description. Text information is coded using the character sets and methods described in annex A. 

Itemjength: This 8-bit field specifies the length in bytes of the item text. 

item„char: This is an 8-bit field. A string of "item.char" fields specify the item text. Text information is 
coded using the character sets and methods described in annex A. 
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textjength: This 8-bit field specifies the length in bytes of the non itemised extended text. 

text_char: This is an 8-bit field. A string of "text_char" fields specify the non itemised extended text. 
Text information is coded using the character sets and methods described in annex A. 

6.2.8 Linkage descriptor 

The linkage descriptor (see table 28) identifies a service that can be presented if the consumer requests 
for additional information related to a specific entity described by the SI system. The location of the linkage 
descriptor in the syntax indicates the entity for which additional information is available. For example a 
linkage descriptor located within the NIT shall point to a service providing additional information on the 
network, a linkage descriptor in the BAT shall provide a link to a service informing about the bouquet, etc. 

A CA replacement service can also be identified using the linkage descriptor. This service may be 
selected automatically by the IRD if the CA denies access to the specific entity described by the 
SI system. 



Table 28: Linkage descriptor 



Syntax 


No. 
of bits 


Identifier 


linkaQe_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


transport_stream_id 


16 


uimsbf 


originaLnetworkJd 


16 


uimsbf 


service id 


16 


bslbf 


linkage_type 


8 


uimsb 


for (i=0;i<N;i++){ 






private data byte 


8 


bslbf 


> 






} 







Semantics for the linkage descriptor: 



transport_streamJd: This is a 16-bit field which identifies the Transport Stream containing the 
information service indicated. 

originaLnetworkJd: This 16-bit field gives the label identifying the networkjd of the originating delivery 
system of the information service indicated. 

service_id: This is a 16-bit field which uniquely identifies an information service within a 
Transport Stream. The servicejd is the same as the program_number in the corresponding 
program_map_section. If the iinkage_type field has the value 0x04, then the servicejd field is not 
relevant, and shall be set to 0x0000. 

Iinkage_type: This is an 8-bit field specifying the type of linkage e.g. to information (see table 29). 



Table 29: Linkage type coding 



Linkage_type 


Description 


0x00 


reserved for future use 


0x01 


information service 


0x02 


Electronic Programme Guide (EPG) service 


0x03 


CA replacement service 


0x04 


transport stream containing complete 
Network/Bouquet SI 


0x05 to 0x7F 


reserved for future use 


0x80 to OxFE 


user defined 


OxFF 


reserved for future use 



^ — 
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private_data_byte: This is an 8-bit field, the value of which is privately defined. 
6.2.9 Local time offset descriptor 

The local time offset descriptor (see table 30) may be used in the Time Offset Table to describe country 
specific dynamic changes of the local time offset relative to UTC. 



Table 30: Local time offset descriptor 



Syntax 


No- 
of bits 


Identifier 


locaLtime_offset_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptor_lenqth 


8 


uimsbf 


for{i=0;i<N;i++)( 






country_code 


24 


bslbf 


country_regionJd 


6 


bslbf 


reserved 


1 


bslbf 


local_time_ offset_polarity 


1 


bslbf 


locaLtime_offset 


16 


bslbf 


time_of _change 


40 


bslbf 


next time offset 


16 


bslbf 


) 






) 







Semantics for the local time offset descriptor 



country_code: This 24-bit field identifies a country using the 3-character code as specified in 
ISO 3166 [2]. Each character is coded into 8-bits according to ISO 8859-1 [5] and inserted in order into the 
24-bit field. In the case of that the 3 characters represent a number in the range of 900 to 999, then 
country code specifies a ETSI defined group of countries. These allocations are in ETR 162 [6]. Country 
codes for groups of countries shall be limited to those within a single time zone. 

EXAMPLE: United Kingdom has 3-character code "GBR", which is coded as: 

'01 00 01 1 1 01 00 001 0 01 01 001 0\ 

country_region_id: This 6-bit field identifies a zone in the country which is indicated by country_code. 
This is set to "000000" when there are no different local time zones in the country. 



Table 31 : Coding of country_region_ld 



Country_reglon_id 


Description 


00 0000 


no time zone extension used 


00 0001 


time zone 1 (most easterly region) 


00 0010 


time zone 2 






11 1100 


time zone 60 (most westerly region) 


11 1101 - 11 1111 


reserved 



IocaI_time_offset_polarity: This 1-bit information indicates the polarity of the following locaLoffsetJime. 
If this bit is set to "0" the polarity is positive and the local time is advanced to UTC, (Usually east direction 
from Greenwich) If this bit is set to "1" the polarity is negative and the local time is behind UTC. 

locaLtime_offset: This 16-bit field contains the current offset time from UTC in the range between 
-12hours and +12hours at the area which is indicated by the combination of country_code and 
country_regionJd in advance. These 16-bits are coded as 4-digits in 4-bit BCD in the order hour tens, 
hour, minute tens, and minutes. 

time_of__change: This is a 40-bit field which specifies the date and time in MJD and UTC (see annex C), 
when the time change takes place. This 40-bit field is coded as 16 bits giving the 16 LSBs of MJD 
followed by 24 bits coded as 6 digits in the 4-bit BCD. 
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next_time_offset: This 16-bit field contains the next offset time after the change from UTC in the range 
between -12hours and 4-12hours at the area which is Indicated by the combination of country_code and 
country__regionJd in advance. These 16-bits are coded as 4-digits in 4-bit BCD in the order hour tens, 
hour, minute tens and minutes. 

6.2.10 Mosaic descriptor 

A mosaic component is a collection of different video Images to form a coded video component. 
The information is organized so that each specific Information when displayed appears on a small area of 
a screen. 



Page 42 

Final draft prETS 300 468: October 1996 

The mosaic descriptor gives a partitioning of a digital video component into elementary cells, the allocation 
of elementary cells to logical cells, and gives a link between the content of the logical cell and the 
corresponding information (e.g.: bouquet, service, event etc.); see table 32. 



Table 32: Mosaic descriptor 



Syntax 


No. 
of bits 


identifier 


mosaic„descriptor(){ 






descriptor__tag 


8 


uimsbf 


descriptor„length 


8 


uimsbf 


mosaic_entry_point 


1 


bslbf 


number_of_horizontal_elementary_cells 


3 


uimsbf 


reserved future use 


1 


bslbf 


number_of_verticaLelementary cells 


3 


uimsbf 


for (i-0,i<N; !++) { 






loglcal_celMd 


6 


uimsbf 


reserved_future use 


7 


bslbf 


logical cell_presentation info 


3 


uimsbf 

VI III 1 1 


elenientary cell field length 


8 


uimsbf 

VI III 1 W*i^l 


for (i=0,i<elementary cell field length;i++) { 






reserved future use 


2 


bslbf 


elementary cell id 


6 


1 jim*?hf 








cell linkage info 


8 


i lim^hf 

U II 1 lOlw/l 


If (cell linkage info ==0x01 ){ 






bouquet id 


16 


uimsbf 

VI lit lO 1 








If (celMinkage info ==0x02){ 






original network id 


16 


1 jim^thf 

U II 1 lOL^I 


transport stream id 


16 


uimsbf 


service id 


16 


uimsbf 

VI III V/ 1 


) 






If (celMinkage_info ==0x03) { 






originaLnetworkJd 


16 


uimsbf 


transport„stream_id 


16 


uimsbf 


service id 


16 


uimsbf 








If (celljinkagejnfo ==0x04){ 






originaLnetworkJd 


16 


uimsbf 


transport_stream_id 


16 


uimsbf 


service id 


16 


uimsbf 


event id 


16 


uimsbf 


) 






} 






} 







Semantics for the Mosaic Descriptor 



mosalc_entry_point: This is a 1-bit field which when set to a value of "1 " indicates that the mosaic is the 
highest mosaic in a hierarchy. A complete mosaic system could be organized in a tree structure, the flag 
being set to identify the entry point in the tree. 
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number_of_horizontal_elementary_cells: This 3-bit field indicates the number of cells of horizontal 
screen display, see table 33 for coding. 



Table 33: Coding of horizontal_elementary_cells 



Value 


Meaning 


0x00 


one cell 


0x01 


two cells 


0x02 


three cells 


0x03 


four ceils 


0x04 


five cells 


0x05 


six cells 


0x06 


seven cells 


0x07 


eight cells 



number_of_verticaLelementary_ce!ls: This 3-bit field indicates the number of cells of vertical screen 
display, see table 34 for coding. 



Table 34; Coding of verticaLelementary_cells 



Value 


Meaning 


0x00 


one cell 


0x01 


two cells 


0x02 


three cells 


0x03 


four cells 


0x04 


five cells 


0x05 


six cells 


0x06 


seven cells 


0x07 


eight cells 



!ogicaI_celLld: This 6-bit field is coded in binary form. 

Different adjacent (see figure 3) elementary cells may be grouped together to form a logical cell. 
A loglcaLcelLnumber is associated to such a group of adjacent elementary_celljds. The total number of 
logical cells shall not exceed the number of elementary cells (maximum = 64). Each elementary cell shall 
be allocated to one logical cell. More than one elementary cell may belong to one logical cell. 



A 


B 


C 


D 


E 


F 


G 


H 


1 



Cells B. D, H, F are adjacent to cell E; C is not adjacent to A or D; D is not adjacent to H. 

Figure 3: Adjacent cells 

logicaLcell_presentation_info: This 3-bit field identifies the type of presentation for a logical cell. 
The logical_cell_presentation information allows an identification of presentation styles, which are defined 
in table 35. 



Table 35: Coding of iogical_cell_presentation_info 



Value 


Meaning 


0x00 


undefined 


0x01 


video 


0x02 


still picture (Note) 


0x03 


graphics/text 


0x04 to 0x07 


reserved for future use 



NOTE 1; Still picture; A coded still picture consists of a video sequence containing exactly one 
coded picture which is intra-coded. 
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elementary_celLfield_length: The elementary_ceil_fieldjength is an 8-bit field specifying the number 
of bytes following this field up to and including the last elementary _celUd in this logicaLcellJd loop. 

elementary_cell_id: This 6-bit field indicates in binary form the number of the cell. The value of this field 
is in the range 0 to N. 

NOTE 2: The elementary cells are implicitly numbered from 0 to N. The value 0 is allocated to 
the cell of the first row (top left corner). This number is incremented from left to right 
and from top to bottom in such a way that the number N is allocated to the cell of the 
last position of the last row (bottom right corner). 

celUinkageJnfo: This 8-bit field identifies the type of information carried in a logical cell, see table 36 for 
coding. 



Table 36: Coding of celUinkageJnfo 



Value 


Meaning 


0x00 


undefined 


0x01 


bouquet related 


0x02 


service related 


0x03 


other mosaic related 


0x04 


event related 


0x05 to OxFF 


reserved for future use 



bouquet_id: This is a 16-bit field which serves as a label to identify the bouquet described by the cell. 

original_network_id: This 16-bit field is a label (see subclause 5.2) which in conjunction with the 
following fields uniquely identifies a service, event or mosaic. 

transport_stream_id: This is a 16-bit field which serves as a label identifying the transport stream which 
contains the service, event or mosaic described by the cell. 

service_id: This is a 16-bit field which identifies a service within a transport stream. The servicejd is the 
same as the program_number in the corresponding program_map_section. 

The interpretation of this field is context sensitive, dependent on the value of celUinkage_info: 

when celUinkageJnfo = "0x02", this is the servicejd of the service described by the cell. 

when celljinkagejnfo = "0x03", this is the servicejd of the mosaic service described by the cell. 

when celljinkagejnfo = "0x04", this is the servicejd of the service to which the event described by 
the cell belongs. 

event Jd: This is a 16-bit field containing the identification number of the described event. 
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6.2.1 1 Multilingual bouquet name descriptor 

The multilingual bouquet name descriptor (see table 37) provides the bouquet name in text form in one or 
more languages. 



Table 37: Multilingual bouquet name descriptor 



Syntax 


No. 

of bits 


identifier 


multilinguaLbouquet_name descriptorO{ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i-H-) { 






ISO_639 lanquaqe code 


24 


bslbf 


bouquet name length 


8 


uimsbf 


for (i=0;i<N:i++){ 






char 


8 


uimsbf 














} 







Semantics for the multilingual bouquet name descriptor: 



ISO_639_language_code: This 24-bit field contains the ISO 639.2 three character language code of the 
language of the following bouquet name. Both ISO 639.2/B and ISO 639.2yT may be used. Each character 
is coded into 9 bits according to ISO 8859-1 and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which Is coded as: 

'011001100111 00100110 olor. 

bouquet_name_length: This 8-bit field specifies the length in bytes of the following bouquet name, 

char: This Is an 8-blt field. A string of char fields specify the name of the bouquet about which the 
BAT sub-table informs In the language specified. Text information is coded using the character sets and 
methods described in annex A. 

6,2.12 Multilingual component descriptor 

The multilingual component descriptor (see table 38) provides a text description of a component In one or 
more languages. The component is identified by its component tag value. 



Table 38: Multilingual component descriptor 



Syntax 


No. 
of bits 


Identifier 


multilinguaLcomponent descriptorOf 






descriptor tag 


8 


uimsbf 


descriptor lenqth 


8 


uimsbf 


component tag 


8 


uimsbf 


for {l=0;l<N;l++) ( 






ISO 639 language code 


24 


bsibf 


text description length 


8 


uimsbf 


for (j=0;j<N:i++)( 






text char 


8 


uimsbf 


> 






) 






} 
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Semantics for the multilingual component descriptor: 

component_tag: This 8-bit field has the same value as the component_tag field in the stream identifier 
descriptor (If present in the PS! program map section) for the component stream. 

ISO_639_language_code: This 24-blt field identifies the language of the following text description of the 
component. The ISO_639Janguage_code contains a 3-character code as specified by ISO 639.2 [3]. 
Both ISO 639.2/B and ISO 639.2/T may be used. Each character is coded into 9 bits according to 
ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'011001100111 001001100101'. 

text_description_length: This 8-bit field specifies the length in bytes of the following text description. 

text„char: This is an 8-bit field. A string of "text_char" fields specifies a text description of the component 
stream. Text information is coded using the character sets and methods described in annex A. 

6,2-13 Multilingual network name descriptor 

The multilingual network name descriptor (see table 39) provides the network name in text form in one or 
more languages. 



Table 39: Multilingual network name descriptor 



Syntax 


No. 
of bits 


Identifier 


multilinguaLnetwork_name descriptor(){ 






descriptor„tag 


8 


uimsbf 


descriptorjenqth 


8 


uimsbf 


for (i=0;i<N;i+-i-) ( 






ISO_639 language code 


24 


bslbf 


network_name length 


8 


uimsbf 


for (i=0:i<N:i++){ 






char 


8 


uimsbf 


> 












} 







Semantics for the multilingual network name descriptor: 



ISO_639Janguage_code: This 24-bit field contains the ISO 639.2 three character language code of the 
language of the following network name. Both ISO 639.2/B and ISO 639,2/T may be used. Each character 
is coded into 9 bits according to ISO 8859-1 and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'011001100111 ooiooiiooior. 

network_name_length: This 8-bit field specifies the length in bytes of the following network name. 

char: This is an 8-bit field. A string of char fields specify the name of the network about which the NIT 
informs in the language specified. Text information is coded using the character sets and methods 
described in annex A. 
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6.2.14 Multilingual service name descriptor 

The multilingual sen/ice name descriptor (see table 40) provides the names of the service provider and 
service in text form in one or more languages. 



Table 40: Multilingual service name descriptor 



Syntax 


No. 
of bits 


Identifier 


multlllnguaLservice_name_descriDtor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i++) { 






ISO_639_language_code 


24 


bslbf 


service_provjder_name length 


8 


uimsbf 


for (i=0:i<N;i++)( 






char 


8 


uimsbf 








service_name length 


8 


uimsbf 


for (i=0;i<N;i++)( 






char 


8 


uimsbf 


> 












} 







Semantics for the multilingual service name descriptor: 



ISO_639Janguage_code: This 24-bit field contains the ISO 639.2 three character language code of the 
language of the following text fields. Both ISO 639.2/B and ISO 639.2/T may be used. Each character is 
coded into 9 bits according to ISO 8859-1 and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'011001100111 ooiooiiooior. 

service_provider_nameJength: This 8-bit field specifies the length in bytes of the following service 
provider name. 

service_namejength: This 8-bit field specifies the length in bytes of the following service name. 

char: This is an 8-bit field. A string of char fields specify the name of the service provider or service. Text 
information is coded using the character sets and methods described in annex A. 

6.2.15 Near Video On Demand (NVOD) reference descriptor 

This descriptor, in conjunction with the time shifted service and time shifted event descriptors, provides a 
mechanism for efficiently describing a number of services which carry the same sequence of events, but 
with the start times offset from one another. Such a group of time-shifted services is referred to as Near 
Video On Demand, since a user can at any time access near to the start of an event by selecting the 
appropriate service of the group. 

The NVOD reference descriptor (see table 41) gives a list of the sen/ices which together form a 
NVOp service. Each service is also described in the appropriate SDT sub_table by a time shifted service 
descriptor, see subclause 6.2.29. The time shifted sen/ice descriptor associates a time shifted service with 
a reference„servicejd. The reference_servicejd is the label under which a full description of the NVOD 
service is given, but the reference_servicejd does not itself correspond to any program_number in the 
program_map_section. 

The time shifted event descriptor is used in the event information for each time shifted sen/ice. Instead of 
duplicating the full infomiation for each event, the time shifted event descriptor points to a 
reference_eventjd in the reference service. The full event information is provided in the event information 
for the reference service. 
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The sen/ices which make up an NVOD service need not all be carried in the same Transport Stream 
However, a reference service shall be described in the SI in each Transport Stream which carries anv 
services of the NVOD sen/ice. 

Table 41: NVOD reference descriptor 



Syntax 


viO. 

of bits 


Identifier 


NVO Dereference descriptorOf 






descriptor taq 


8 


uimsbf 


descriptorjenqth 


8 


uimsbf 


for (i=0;i<N;i++) { 






transport stream id 


16 


uimsbf 


oriaina! network id 


16 


uimsbf 


service id 


16 


uimsbf 


) 






} 







Semantics for the NVOD reference descriptor: 

transport_streamJd: This is a 16-bit field which identifies the Transport Stream. 

syLfe'J^ "'"^'^ ^'^'^ ^^^^ identifying the network Jd of the originating delivery 

servicejd: This is a 16-bit field which uniquely identifies a service within a Transport Stream 
The service_id is the same as the program_number in the corresponding program_map_section. 

6.2.16 Network name descriptor 

The network name descriptor provides the network name in text form. See table 42. 

Table 42: Network name descriptor 



Syntax 


No. 
of bits 


identifier 


network_name descriptorOf 






descriptor taq 


8 


uimsbf 


descriptor lenqth 


8 


uimsbf 


for (i=0;i<N;i++){ 






char 


8 


uimsbf 








} 







Semantics for the network name descriptor: 

char: This is an 8-bit field. A string of char fields specify the name of the delivery system about which the 
NIT informs. Text infonnation is coded using the character sets and methods described in annex A. 
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6.2.17 Parental rating descriptor 

This descriptor (see table 43) gives a rating based on age and allows for extensions based on other rating 
criteria. 



Table 43: Parental rating descriptor 



Syntax 


No. 
of bits 


Identifier 


parental_rating_descriptor()( 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i++){ 






country_code 


24 


bslbf 


rating 


8 


uimsbf 








} 







Semantics for the parental rating descriptor: 



country_code: This 24-bit field identifies a country using the 3-character code as specified in 
ISO 3166 [2]. Each character is coded into 8-bits according to ISO 8859-1 [5] and inserted in order into the 
24-bit field. In the case that the 3 characters represent a number in the range 900 to 999, then 
country__code specifies a ETSi defined group of countries. These allocations are found In ETR 162 [6]. 

EXAMPLE: United Kingdom has 3-character code "GBR", which is coded as* 

'0100 0111 0100 0010 0101 0010'. 

rating: This 8-bit field is coded according to table 44, giving the recommended minimum age in years of 
the end user. 



Table 44: Parental rating descriptor, rating 



Rating 


Description 


0x00 


undefined 


0x01 to OxOF 


minimum age ~ rating + 3 years 


0x10 to OxFF 


defined by the broadcaster 



EXAMPLE: 0x04 implies that end users should be at least 7 years old. 

6.2.1 a Private data specifier descriptor 

Some values of descriptor_tag and other fields in this ETS are specified as user-defined. These values 
facilitate compatible private extensions to the SI data stream. However, for this private information to be 
interpreted reliably by the IRD. the specifier of the meaning of the user-defined values must be known to 
the IRD. The private_data_specifier_descriptor (see table 45) identifies the specifier to the IRD. The scope 
of this descriptor depends on its location in accordance with the following rules: 

1) If this descriptor is located in the first descriptor loop of the NIT, then it shall apply to all descriptors 
in the NIT for that network that have private tags, as well as to all user-defined fields of DVB 
descriptions in the NIT for that network. 

2) If this descriptor is located in the first descriptor loop of the BAT, then it shall apply to all descriptors 
in the BAT for that bouquet that have private tags, as well as to all user-defined fields of DVB 
descriptions in the BAT for that bouquet. 

3) If this descriptor is located in the SDT. then it applies to all descriptors for that servicejd in both the 
SDT and EIT that have private tags, as well as to all user-defined fields of DVB descriptions in 
those tables. 
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4) Within any EIT descriptor loop, or BAT or N!T second descriptor loop, the default specifier given by 
the above rules is overridden by any instances of the private_data_specifier_descriptor. 
The specifier given in the descriptor applies to all following descriptors in the particular loop until the 
end of the loop, or until another occurrence of a private„data_specifier_descriptor. 



Table 45: Private data specifier descriptor 



Syntax 


No. 
of bits 


Identifier 


private_data_specifier_descriptor(){ 






descrlptor_tag 


8 


uimsbf 


descriptor_length 


8 


uimsbf 


private_data_specifier 


32 


uimsbf 


) 







Semantics for the private data specifier descriptor: 



private_data_speclfier: The assignment of values for this field is given in ETR 162 [6]. 
6.2.19 Short smoothing buffer descriptor 

A smoothing_buffer_descriptor is specified in ISO/IEC 13818-1 which enables the bit-rate of a service to 
be signalled in the RSI. For use in DVB SI Tables, a more compact and efficient descriptor, the 
short_smoothing„buffer_descriptor (table 46), is defined here. This descriptor may be included in the 
EIT Rresent/Following and EIT Schedule Tables to signal the bit-rate for each event. The bit rate is 
expressed in terms of a smoothing buffer size and output leak rate. The presence of the descriptor in the 
EIT Rresent/Following and EIT Schedule Tables is optional. 

The data flows into and from the smoothing buffer are defined as follows: 

bytes of Transport Stream packets belonging to the associated service are input to the smoothing 
buffer at the time defined by equation 2 - 4 of ISO/IEC 13818-1 (definition of the mathematical byte 
delivery schedule). The following packets belong to the service: 

all Transport Stream packets of all elementary streams of the service, i.e. all RIDs which are 
listed as elementary_RIDs in the extended program information part of the RMT section for 
the service during the time that the event is transmitted; 

all Transport Stream packets of the RID which is identified as the program_map_RID for the 
service in the PAT at the time that the event is transmitted; 

all Transport Stream packets of the RID which is Identified as the RCR_RID in the RMT 
section for the service at the time that the event is transmitted. 

all bytes that enter the buffer also exit it. 



Table 46: Short smoothing buffer descriptor 



Syntax 


No. 
of bits 


Identifier 


short_smoothing_buffer_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


sb size 


2 


uimsbf 


sbjeak_rate 


6 


uimsbf 


for (i=0;i<N;i++){ 






DVB reserved 


8 


bslbf 


) 






} 
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Semantics for the short smoothing buffer descriptor: 

sb_size: This 2-bit field indicates the size of the smoothing buffer, and is coded according to table 47. 



Table 47: Smoothing buffer size 



Value 


Buffer size (bytes) 


0 


DVB_reserved 


1 


1 536 


2 


DVB_reser^ed 


3 


DVB_resen/ed 



NOTE: Due to implementation constraints, the specified buffer size value considers spare 
capacity that may be required in a 2 kbyte RAM for packet jitter. 



sbjeak_rate: This 6-bit field indicates the value of the leak rate from the buffer, and is coded 
to table 48. 
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Table 48: Smoothing buffer leak rate 



Value 


Leak rate (Mbit/s) 


0 


DVB_reserved 


1 


0,0009 


2 


0,0018 


3 


0,0036 


4 


0,0072 


5 


0,0108 


6 


0,0144 


7 


0,0216 


8 


0,0288 


9 


0,075 


10 


0,5 


11 


0,5625 


12 


0,8437 


13 


1,0 


14 


1,1250 


15 


1,5 


16 


1,6875 


17 


2,0 


18 


2,2500 


19 


2,5 


20 


3,0 


21 


3,3750 


22 


3,5 


23 


4,0 


24 


4,5 


25 


5,0 


26 


5,5 


27 


6,0 


28 


6,5 


29 


6 7500 


30 - 32 


((value) - 16^*0 ^ 
[ 7, 7,5, 8 Mbit/s ) 


33-37 


((value) - 24) (9,10,11,12,13 Mbit/s 


38 


13,5 


39 - 43 


^^value) - 25^ M4 15 16 17 
18 Mbit/s) 


44 - 47 


((value) - 34)*2 ( 20, 22, 24, 26 Mbit/s ) 


48 


27 


49-55 


((value) - 35)*2 ( 28, 30. 32, ... 40 Mbit/s 


56 


44 


57 


48 


58 


54 


59 


72 


60 


108 


61 -63 


DVB_reserved 
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6.2.20 Service descriptor 

The service descriptor (see table 49) provides the names of the service provider and the service in text 
form together with the service_type. 



Table 49: Service descriptor 



Syntax 


No. 
of bits 


Identifier 


service_descriptor()( 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


service_type 


8 


uimsbf 


service_provider_nameJength 


8 


uimsbf 


for (i=0;i<N;i++){ 






char 


8 


uimsbf 








service_namejength 


8 


uimsbf 


for (i=0;i<N;i++){ 






char 


8 


uimsbf 


) 






) 







Semantics for the service descriptor: 



service_type: This is an 8-bit field specifying the type of the service. It shall be coded according to 
table 50. 



Table 50: Service type coding 



Service_type 


Description 


0x00 


reserved for future use 


0x01 


digital television service 


0x02 


digital radio sound service 


0x03 


teletext service 


0x04 


NVOD reference service 


0x05 


NVOD time-shifted service 


0x06 


mosaic service 


0x07 


PAL coded signal 


0x08 


SECAM coded signal 


0x09 


D/D2-MAC 


OxOA 


FM Radio 


OxOB 


NTSC coded signal 


OxOC to 0x7F 


reserved for future use 


0x80 to OxFE 


user defined 


OxFF 


reserved for future use 



service_provider_name„length: This 8-blt field specifies the number of bytes that follow the 
servlce_provider_nameJength field for describing characters of the name of the service provider. 

char; This is an 8-bit field. A string of char fields specify the name of the service provider or service. Text 
information is coded using the character sets and methods described in annex A. 

service_namejength: This 8-bit field specifies the number of bytes that follow the service_namejength 
field for describing characters of the name of the service. 
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6.2.21 Service list descriptor 

The service list descriptor (see table 51) provides a means of listing the services by servicejd and service 
type. 



Table 51: Service list descriptor 



Syntax 


No. 
of bits 


Identifier 


serviceJist_descriptor(){ 






descriptor„tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i++){ 






service id 


16 


uimsbf 


service type 


8 


uimsbf 


1 






) 







Semantics for the service list descriptor: 



servicejd: This is a 16-bit field which uniquely identifies a service within a Transport Stream. 
The servicejd is the same as the program_number in the corresponding program_map_section, except 
that in the case of service_type = 0x04 (NVOD reference service) the servicejd does not have a 
corresponding program_number. 

servicejype: This is an 8-bit field specifying the type of the service. It shall be coded according to 
table 50. 

6.2.22 Service move descriptor 

If it is required to move a service from one Transport Stream to another, a mechanism is provided which 
enables an IRD to track the service between Transport Streams by means of a service_move_descriptor. 



Table 52: Service move descriptor 



Syntax 


No. 
of bits 


Identifier 


service_move_descriptor(){ 






descriptorjag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


new_oriQinaLnetwork_id 


16 


uimsbf 


newJransport_stream id 


16 


uimsbf 


new service id 


16 


uimsbf 


) 







Semantics for the service move descriptor: 

new_original_networkJd: This field contains the originaLnetworkJd of the Transport Stream in which 
the service is found after the move. 



new_transport_streamJd: This field contains the transport_streamJd of the Transport Stream in which 
the service is found after the move. 

new_servicejd: This field contains the servicejd of the service after the move. If the service remains 
within the same original network, then the new_servicejd is the same as the previous servicejd. 
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6.2.23 Short event descriptor 

The short event descriptor provides the name of the event and a short description of the event in text 
form (see table 53). 



Table 53: Short event descriptor 



Syntax 


No. 
of bits 


Identifier 


short_event_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


ISO_639Janguage„code 


24 


bslbf 


event__namejength 


8 


uimsbf 


for {i=0;i<event_nameJength;i++){ 






event name char 


8 


uimsbf 








text_length 


8 


uimsbf 


for (i=0;i<:textJength;i++){ 






text char 


8 


uimsbf 


) 






} 







Semantics for the short event descriptor: 



ISO_639Janguage_code: This 24-bit field contains the ISO 639 [3] three character language code of the 
language of the following text fields. Both ISO 639.2/B and ISO 639.2/T may be used. Each character is 
coded into 9 bits according to ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'011001100111 ooioonooior. 

event_name_length: An 8-bit field specifying the length in bytes of the event name. 

event_name_char: This is an 8-bit field. A string of "char" fields specifies the event name. 
Text information is coded using the character sets and methods described in annex A. 

textjength: This 8-bit field specifies the length in bytes of the following text describing the event. 

text_char: This is an 8-bit field. A string of "char" fields specify the text description for the event. 
Text information is coded using the character sets and methods described in annex A. 

6.2.24 Stream identifier descriptor 

The stream identifier descriptor (see table 54) may be used in the PSI PMT to label component streams of 
a service so that they can be differentiated, e.g. by text descriptions given in component descriptors in the 
EIT if present. The stream identifier descriptor shall be located following the relevant ESJnfoJength field. 



Table 54: Stream identifier descriptor 



Syntax 


No. 
of bits 


Identifier 


stream_identifier_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


component tag 


8 


uimsbf 


} 
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Semantics for the stream identifier descriptor: 

component_tag: This 8-bit field identifies the component stream for associating it with a description given 
in a component descriptor. Within a program map section each stream identifier descriptor shall have a 
different value for this field. 

6.2.25 Stuffing descriptor 

The stuffing descriptor provides a means of invalidating previously coded descriptors or inserting dummy 
descriptors for table stuffing. See table 55. 



Table 55: Stuffing descriptor 



Syntax 


No. 
of bits 


identifier 


stuffing_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i= 0;i<N;i++){ 






stuffing byte 


8 


bslbf 


) 













Semantics for the stuffing descriptor: 



stuffing_byte: This is an 8-bit field. Each occurrence of the field may be set to any value. The IRDs may 
discard the stuffing bytes. 

6.2.26 Subtitling descriptor 

In the ISO/IEC 13818-1 [1] Program Map Table (PMT) the value of stream_type for any RID carrying DVB 
subtitle shall be "0x06" (this indicates a PES carrying private data). See table 56. 



Table 56: Subtitling descriptor 



Syntax 


No. 
of bits 


Identifier 


subtitling_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i= 0;i<N;i++){ 






1 SO_639_lang uage_code 


24 


bslbf 


subtitling_type 


8 


bsib 


composition_pageJd 


16 


bslbf 


ancillary page id 


16 


bslbf 


) 






} 







Semantics for the subtitling descriptor: 



ISO_639Janguage_code: This 24-bit field contains the ISO 639 [3] three character language code of the 
language of the subtitle. Both ISO 639.2/B and ISO 639.2yT may be used. Each character is coded into 
9 bits according to ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'01 1 0 01 1 0 01 1 1 001 0 01 1 0 01 01 \ 

subtitling_type: This 9 bit field provides information on the content of the subtitle and the intended 
display. The coding of this field shall use the codes defined for component_type when stream_content is 
0x03 in table 16 "stream__content and component_type". 
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composition_page_id: This 16-bit field identifies the composition page. DVB_subtitling_segments 
signalling this pagejd shall be decoded if the previous data in the subtitling descriptor matches the user's 
selection criteria. 

NOTE 1 : The composition_page_id is signalled in at least the DVB_subtitling_segments that 
define the data structure of the subtitle screen; the page_composition_segment and 
region_composition_segments. It may additionally be signalled in segments containing 
data on which the composition depends. 

ancillary_page_id: This identifies the (optional) ancillary page. DVB_subtltllng_segments signalling this 
pagejd shall also be decoded if the previous data in the subtitling descriptor matches the user's selection 
criteria. The values in the ancillary_pagejd and the composition_pageJd fields shall be the same if no 
ancillary page is provided. 

NOTE 2: The ancillary_pagejd is never signalled in a composition segment. It may be signalled 
in GLUT definition segments, object segments and any other type of segment. 

NOTE 3: (Terminology): A segment that signals a particular page number in its pagejd field is 
said to be "in" that page. The page is said to "contain"* that segment. 

6.2.27 Telephone descriptor 

The telephone descriptor may be used to indicate a telephone number, which may be used in conjunction 
with a modem (PSTN or cable) to exploit narrowband interactive channels. Further information is given in 
Implementation Guidelines for the use of Telecommunications Interfaces in Digital Video Broadcasting 
systems (see annex D: bibliography). 

The telephone descriptor syntax is specified in table 57. 
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Table 57: Telephone descriptor 



Syntax 


No. 
of bits 


Identifier 


telephone_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


resen/ed_future_use 


2 


bslbf 


foreign_availability 


1 


bslbf 


connection_type 


5 


uimsbf 


reserved_future_use 


1 


bslbf 


country_prefix_length 


2 


uimsbf 


internationaLarea_code length 


3 


uimsbf 


operator_code_length 


2 


uimsbf 


reserved_future_use 


1 


bslbf 


national_area__code length 


3 


uimsbf 


core_number length 


4 


uimsbf 


for (i=:0;i<N;i++)( 






country prefix char 


8 


uimsbf 








for (i=0;i<N:i++){ 






international area code char 


8 


uimsbf 








for (i=0;i<N;i++)( 






operator code char 


8 


uimsbf 








lor (i=u,i<i>j,i++){ 






national area code char 


8 


uimsbf 








for (i=0;i<N;i++){ 






core nunnber char 


8 


uimsb 















Semantics for the telephone descriptor: 



foreign_availability: This is a 1-bit flag. When set to "1" it indicates that the number described can be 
called from outside of the country specified by the country_prefix. When set to "0" it indicates that the 
number can only be called from inside the country specified by the country_prefix. 

connection_type: This is a 5-bit field which indicates connection types. One example of the use of the 
connection type is to inform the IRD that when, if an interaction is initiated, if the connection is not made 
within 1 minute, then the connection attempt should be aborted. 

country_prefix_length: This 2-bit field specifies the number of 8-bit alphanumeric characters in the 
country prefix. 

internatlonaLarea_code_length: This 3-bit field specifies the number of 8-blt alphanumeric characters 
in the international area code. 

operator_code_length: This 2-bit field specifies the number of 8-bit alphanumeric characters in the 
operator code, 

nationaLarea_codeJength: This 3-bit field specifies the number of 8-bit alphanumeric characters in the 
national area code. 



core_number_length: This 4-bit field specifies the number of 8-bit alphanumeric characters in the core 
number. 
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country„prefix_char: This 8-bit field which shall be coded in accordance with ISO 8859-1 [5] gives one 
alphanumeric character of the country prefix. 

internationaLarea_code_char: This 8-bit field which shall be coded in accordance with ISO 8859-1 [5] 
gives one alphanumeric character of the International area code. 

operator_code_char: This 8-bit field which shall be coded in accordance with ISO 8859-1 [5] gives one 
alphanumeric character of the operator code. 

nationaLarea_code_char: This 8-bit field which shall be coded in accordance with ISO 8859-1 [5] gives 
one alphanumeric character of the national area code. 

core_number_char: This 8-bit field which shall be coded in accordance with ISO 8859-1 [5] gives one 
alphanumeric character of the core number. 

6.2.28 Teletext descriptor 

The teletext descriptor (see table 58) shall be used in the PS! PMT to identify streams which carry EBU 
teletext data. The descriptor is to be located in a program map section following the relevant 
ESJnfoJength field. 



Table 58: Teletext descriptor 



Syntax 


No. 
of bits 


Identifier 


teletext_descriptor(){ 






descriptor_tag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


for (i=0;i<N;i+H-){ 






ISO_639_language_code 


24 


bslbf 


teletext_type 


5 


uimsb 


teletext„maqazine_number 


3 


uimsbf 


teletext page number 


8 


uimsbf 


} 






} 







Semantics for the teletext descriptor: 



ISO_639_language_code: This 24-bit field contains the 3 character ISO 639 [3] language code of the 
language of the teletext. Both ISO 639.2/B and ISO 639.2yT may be used. Each character is coded into 
9 bits according to ISO 8859-1 [5] and inserted in order into the 24-bit field. 

EXAMPLE: French has 3-character code "fre", which is coded as: 

'011001100111 001001100101*. 

teletext_type: This 5-bit field indicates the type of teletext page indicated. This shall be coded according 
to table 59. 



Table 59: Teletext descriptor, teletext_type 



Teletext_tvpe 


Description 


0x00 


reserved for future use 


0x01 


initial teletext page 


0x02 


teletext subtitle page 


0x03 


additional information page 


0x04 


programme schedule page 


. 0x05 to 0x1 F 


reserved for future use 



teletext_magazine_number: This is a 3-bit field which identifies the magazine number as defined in 
EBU SPB 492 [4]. 
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teletext_page„number: This is an 8-bit field giving two 4-bit hex digits Identifying the paae number as 
defined in EBU SPB 492 [4]. 

6.2.29 Time shifted event descriptor 

The time shifted event descriptor (see table 60) is used in place of the short_event_descriptor to indicate 
an event which is a time shifted copy of another event. 

Table 60: Time shifted event descriptor 



Syntax 


No. 
of bits 


Identifier 


time_shjfted_event_descriptorO( 






descriptor_tag 


8 


uimsbf 


descriptorjenqth 


8 


uimsbf 


reference_service id 


16 


uimsbf 


reference event id 


16 


uimsbf 


} 







Semantics for the time shifted event descriptor: 

reference_servicejd: This 16-bit field identifies the reference service of a NVOD collection of services 
The reference service can always be found in this Transport Stream. The service Jd here does not have a 
corresponding program_number in the program_map_section. 

reference_event_id: This 16-bit field Identifies the reference event of which the event described by this 
descnptor is a time shifted-copy. ^ 

6.2.30 Time shifted service descriptor 

This descriptor is used in place of the service descriptor to Indicate sen/ices which are time shifted copies 
of other services (see table 61). 

Table 61: Time shifted service descriptor 



Syntax 


No. 
of bits 


Identifier 


time_shifted_service descriptor()( 






descriptor tag 


8 


uimsbf 


descriptor length 


8 


uimsbf 


reference service id 


16 


uimsbf 


} 







Semantics for the time shifted service descriptor: 

reference_service_id: This 16-bit field identifies the reference service of a NVOD collection of services 
The reference service can always be found in this Transport Stream. The servicejd here does not have a 
corresponding program_number in the program_map_section. 
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Annex A (normative): Coding of text characters 

Text items can optionally include information to select a wide range of character tables as indicated below. 
For the European languages a set of five character tables are available. If no character selection 
information is given in a text item, then a default character set is assumed. 

A.1 Control codes 

The codes in the range 0x80 to 0x9F are assigned to control functions as shown in table A.1. 



Table A.I : Single Byte Control codes 



Control code 


Description 


0x80 to 0x85 


reserved for future use 


0x86 


character emphasis on 


0x87 


character emphasis off 


0x88 to 0x89 


reserved for future use 


0x8A 


CRA-F 


0x8B to 0x9F 


user defined 


For two-byte character tables, the codes in the range OxEOSO to 0xE09F are assigned to control functions 
as shown in table A.2. 

Table A.2: DVB codes within Private Use Area of ISO/IEC 10646-1 [8] 


Control code 


Description 


0xE080 to 0xE085 


reserved for future use 


0xE086 


character emphasis on 


0xE087 


character emphasis off 


0xE088 to 0xE089 


reserved for future use 


OxEOSA 


CR/LF 


0xE08B to 0xE09F 


reserved for future use 



A.2 Selection of character table 



Text fields can optionally start with non-spacing, non-displayed data which specifies the alternative 
character table to be used for the remainder of the text item. The selection of character table is indicated 
as follows: 

if the first byte of the text field has a value in the range "0x20" to "OxFF" then this and all 
subsequent bytes in the text item are coded using the default character coding table (table 00 - 
Latin alphabet) of figure A.1 ; 

if the first byte of the text field has a value in the range "0x01" to "0x05" then the remaining bytes in 
the text item are coded in accordance with character coding tables 01 to 05 respectively, which are 
given in figures A.2 to A.6 respectively; 

if the first byte of the text field has a value "0x10" then the following two bytes carry a 16-bit value 
(uimsbf) N to indicate that the remaining data of the text field is coded using the character code 
table specified by ISO Standard 8859-1 to 9 [5]; 

if the first byte of the text field has a value "0x1 1 " then the remaining bytes in the text item are 
coded in pairs in accordance with the Basic Multilingual Plane of ISO/IEC 10646-1 [8]. 



Values for the first byte of "0x00", "0x06" to "OxOF", and "0x12" to "0x1 F" are reserved for future use. 
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NOTE 1: 
NOTE 2: 
NOTE 3: 
NOTE 4: 
NOTE 5: 



The SPACE character is located in position 20h of the code table. 
NBSP - no-break space. 
SHY = soft hyphen. 

Table reproduced from ISO/IEC 6937 [9]. 

All characters in column C are non-spacing characters (diacritical marks). 
Figure A.1: Character code table 00 - Latin alphabet 
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Second 
nibble 

0 
1 
2 
3 
4 
5 
6 
7 
8 
9 
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B 
C 
D 
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NOTE 1: 
NOTE 2: 
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For the Ruthenian language, the characters In code positions Ah/5h (S) and Fh/5h (s) are 
replaced by P and P, respectively. 

Table reproduced from ISO 8859-5 [5]. 

Figure A.2: Character code table 01 - Latin/Cyrillic alphabet 
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Second 
nrbble 



First nibble 
D T 2 




NOTE: 



Table reproduced from ISO 8859-6 [5]. 

Figure A.3: Character code table 02 - Latin/Arabic alphabet 
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Second 
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NOTE: 



Table reproduced from ISO 8859-7 [5]. 
Figure A.4: Character code table 03 



- Latin/Greek alphabet 
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Second 
nibble 
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Table reproduced from ISO 8859-8 [5]. 
Figure A.5: Character code table 04 - Latin/Hebrew alphabet 
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nibble 



2 

3 

4 

5 

6 

7. 

8 

9 

A 

B 

C 

D 

El 

F 



First nibble - 
0 1 2 



3 4 



SP 



$ 



% 



0 I a 



2 B 



3 C 



4 D 



5 E 



6 F 



7 I G 

8 I H 

9 I 



= I M 

> N 



R b 



T d 



U 



W 

Fj h 



C |k 

\ L 



m 



n 



<BSPl 



I I X 



s ^Mi^ / 



u 



IT 



w § 



y ©I ^ 



« » 



AG 



A 



N 



0 



0 



0 



JU 

u 



3 



n 



0 

u 
u 

u 
u 



NOTE: 



Table reproduced fronn ISO 8859-9 [5]. 
Figure A.6: Character code table 



Latin alphabet number 5 
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Annex B (normative): CRC decoder model 

The 32-bit CRC decoder is specified In figure B.1 . 



Received data and CRC-32 bits 
(most significant bit first) — 




0 0 0 



Figure B.I : 32-bit CRC decoder model 

The 32 bit CRC decoder operates at bit level and consists of 14 adders + and 32 delay elements z(i) The 
input of the CRC decoder is added to the output of z(31). and the result is provided to the input z(O) and to 
one of the inputs of each remaining adder. The other input of each remaining adder is the output of z(i) 
while the output of each remaining adder is connected to the input of z(i+1). with i = 0, 1 , 3 4 6 7 9 10 
11, 15, 21, 22, and 25. See figure above. 

This is the CRC calculated with the polynomial: 

x32^x26^x23^^2^^16^^12^x11^^10^^^^7^^5^^^^2^x^1 

At the input of the CRC decoder bytes are received. Each byte is shifted into the CRC decoder one bit at a 

h'^^c^v^n -n- ^"l^^^ ^y*® 'ast byte of the startcode prefix), first 

the seven 0 s enter the CRC decoder, followed by the one "1". Before the CRC processing of the data of 
a section the output of each delay element z(i) is set to its initial value "1". After this initialization, each byte 
thi iLf K 11^?""^™ *o® L"P"* °^ decoder, including the four CRC_32 bytes. After shifting 

the last bit of the ast CRC_32 byte into the decoder, i.e. into z(0) after the addition with the output of 
z(31). the output of all delay elements z(i) is read. In case of no errors, each of the outputs of z(i) has to be 
zero. At the CRC encoder the CRC_32 field is encoded with such value that this is ensured 
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Annex C (informative): Conversion between time and date conventions 

The types of conversion which may be required are summarized in the diagram below. 



MJD + UTC 




subtract 



Week- 


Week 


Year 


number 



Offsets are positive for Longitudes East of Greenwich and negative for longitudes 
West of Greenwich. 

Figure C.1: Conversion routes between Modified Julian Date (MJD) and 
Co-ordinated Universal Time (UTC) 

The conversion between MJD + UTC and the "local" MJD + local time is simply a matter of adding or 
subtracting the local offset. This process may, of course, involve a "carry" or "borrow" from the UTC 
affecting the MJD. The other five conversion routes shown on the diagram are detailed in the formulas 
below. 



Symbols used: 

MJD: 

UTC: 

Y: 

M: 

D: 

WY: 
MN: 
WD: 

K. L ,M' , W, Y*: 

x: 

int: 

mod 7: 



Modified Julian Day 

Co-ordinated Universal Time 

Year from 1900 (e.g. for 2003, Y = 103) 

Month from January (= 1) to December (= 12) 

Day of month from 1 to 31 

"Week number" Year from 1 900 

Week number according to ISO 2015 

Day of week from Monday (= 1) to Sunday (= 7) 

Intermediate variables 

Multiplication 

Integer part, ignoring remainder 
Remainder (0-6) after dividing integer by 7 



a) To find Y, M, D from MJD 

r = int [ (MJD - 1 5 078,2) / 365.25 ] 

M' = int { [ MJD - 14 956.1 - int (Y' x 365,25) ] / 30,6001 } 

D = MJD - 14 956 - int (Y' x 365.25) - int (M' x 30,6001 ) 

If M' = 14 or M' = 15. then K = 1; else K = 0 

Y = Y' + K 

M = M'-1-Kx12 
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b) To find MJD from Y, M, D 

If M = 1 or M = 2, then L = 1 ; else L = 0 

MJD = 14 956 + D + int [ (Y - L) x 365,25] + int [ (M + 1 + L x 12) x 30,6001 ] 

c) To find WD from WJD 

WD = f (MJD + 2) mod 7 ] + 1 

d) To find MJD from WY, WN, WD 

WJD = 15 012 + WD + 7 X { WN + int [ (WY x 1 461 / 28) + 0,41] } 

e) To find WY. WN from MJD 

W = int [ (MJD / 7) - 2 144,64 ] 
WY = int [ (W X 28 / 1 461 ) - 0,0079] 
WN = W - int [ (WY x 1 461 / 28) + 0,41] 

EXAMPLE: MJD = 45 218 W = 4 315 

Y = (19)82 WY = (19)82 

M = 9 (September) WN = 36 

^ = 6 WD = 1 (Monday) 



These formulas are applicable between the inclusive dates 1 900 
2 100 February 28. 



March 1 to 
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